ParsePattern: allow identifiers starting with $ in protocol declaration.

[ashdnazg]

This enables protocols to require the existence of certain projected values in conforming types:

protocol ProtocolWithProjectedValue {
  var foo: Int { get set }
  var $foo: Wrapper<Int> { get }
}

struct StructWithPropertyWrapper: ProtocolWithProjectedValue {
  @Wrapper var foo = 1337
}

It is mentioned in the comments here: https://forums.swift.org/t/property-wrapper-requirements-in-protocols/33953 but that proposal seems to be stuck.
As opposed to the full proposal, this PR is a low hanging fruit (one line of code changed) that gives almost the same new capabilities to the developer.
From the desugaring point of view, this PR can also be seen as a prerequisite of the aforementioned proposal.

[Sajjon]

Yay! This will solve my problem https://stackoverflow.com/q/57652925

[farzadshbfn]

I am not part of the swift team, but out of curiosity, but looking at the change, it seems it allows definition of variables with $ prefix inside protocols. I think this change requires more than just enabling it inside protocols, custom errors generated also should be clear. For example in following cases:

protocol ProtocolWithDollarSignProperty {
    var foo: String { get } 
    var $foo: Wrapper<Int> { get }
}

This protocol can never be satisfied by any type trying to implement it (as the foo type is different from Wrapper generic type). I believe, language should prohibit introduction of such codes.

[ashdnazg]

It is actually possible, even if a bit insane:

@propertyWrapper
struct InsaneWrapper<Value> {
  var wrappedValue: Value

  var projectedValue: Wrapper<Int> {
    .init(wrappedValue: 5)
  }
}

struct ConformingStruct: ProtocolWithDollarSignProperty {
  @InsaneWrapper var foo: String
}

Property wrappers seem to allow you to project arbitrary values, the only thing we constrain in the protocol is the type of the projected value, not its meaning.

[rakuyoMo]

This feature is very much needed and this feature is very useful for me.