This PR does some cleanups in the parser base that should make it easier to implement the changed
fewerBraces rules where the lambda is now preceded by :.

The problem is that this creates two ambiguities:

1. With self types:

    class C { self: T => 
       x = x + 1
    }

   can be alternatively read as a function application of self to a lambda. The first commit solves this
   by defaulting to a self type if the code appears at the start of a template. In the long run, this would not
   be a problem since we want to move away from self types and replace them by a This type declaration.
   But for now we need to fix the ambiguity.

2. With the way formal parameters of lambdas are parsed. Consider the expression:

   (x: Int => Int) => Int

   Here, we used to parse (x: Int => Int) as an expression (i.e. an ascription with a Typed node) and then converted this to a parameter ValDef when the second => was encountered. Because of this hack, we
   had to allow function types like Int => Int in type ascriptions inside parentheses, but not elsewhere, even though this relaxation is not backed by the official Scala syntax. With fewerBraces the first expression inside (...) would be parsed as an application of the form x(y => z), which would complicate things further.

   The second commit solves this by lookahead scanning when a : ascription inside parentheses is encountered. If the closing parenthesis is followed by => or ?=> we classify the prefix as a list of bindings and parse appropriately. No need to convert type ascriptions to parameters.

The third commit enforces the official Scala grammar, requiring (...) around function types in ascriptions. It is enabled from source version 3.2.

Fixes #15260