Support function and operation types without parentheses

[bamarsha]

This PR changes the syntax for function and operation types. Parentheses are optional in most cases. You can write:

function Foo(f : Int -> Int -> Int) : Int -> Int {
    return f(1);
}

instead of

function Foo(f : (Int -> (Int -> Int))) : (Int -> Int) {
    return f(1);
}

Parentheses are required when a callable type is used as the item type of an array. For example, (Int -> Int)[], (Qubit => Unit is Adj)[], or new (Qubit => Unit is Adj)[3].

Two breaking changes were made, which we expect to have minimal impact on existing code:

1. Remove support for using a colon to start operation characteristics, e.g. Qubit => Unit : Adjoint. This syntax has been deprecated for a while.
2. Remove support for parentheses around the arrow and before the characteristics in operation types, e.g. ((Qubit => Unit) is Adj). This must be written as (Qubit => Unit is Adj) or Qubit => Unit is Adj.

The reason for the second change is to distinguish between these two cases:

operation Foo() : Qubit => Unit is Adj {
    // ...
}

operation Bar() : (Qubit => Unit) is Adj {
    // ...
}

This PR defines the meaning of this example to be:

1. Foo returns a value of type Qubit => Unit is Adj. Foo is not adjointable.
2. Bar returns a value of type Qubit => Unit. Bar is adjointable. This is a type error, because adjointable or controllable operations must return Unit, but allowing this to be parsed keeps the possibility open for future language development related to this.

Closes #788.

[ScottCarda-MS]

I was wondering if we could have a more formal design review for this feature (#788). (Or maybe we already did and I missed it?) There are some questions I have going into this that I would want to talk about over a meeting and that would give people the opportunity to chime in with their questions and comments.

[bamarsha]

@ScottCarda-MS Could you post your comments/questions here or in issue #788?

[ScottCarda-MS]

@ScottCarda-MS Could you post your comments/questions here or in issue #788?

@SamarSha Is that to say that you will not be doing a formal design review for this?

[bamarsha]

@ScottCarda-MS It would be helpful to understand specifically what your concerns are with this change. While it is technically a change to the language that could go through the Q# proposal process, @bettinaheim and I feel that since it's a relatively minor change to parsing, it could go through normal PR review for the compiler instead.

If you post your concerns, we can see if we can address them here or if we need more discussion in a language proposal.

[bettinaheim]

@ScottCarda-MS It would be helpful to understand specifically what your concerns are with this change. While it is technically a change to the language that could go through the Q# proposal process, @bettinaheim and I feel that since it's a relatively minor change to parsing, it could go through normal PR review for the compiler instead.

If you post your concerns, we can see if we can address them here or if we need more discussion in a language proposal.

I agree. Since this change merely allows to omit some parenthesis that were previously required, I don't think that warrants a full proposal. The usage of e.g. (Int -> Int) will continue to work. Additionally, Int -> Int is now supported with this PR as well.