Synthesize accessors, fields (and bitmaps) for (lazy) vals and modules.

During Namers, a ValDef that is lazy, deferred and/or defined in a trait carries its getter's symbol. The underlying field symbol does not exist until this phase.

For vals defined in classes, we still emit a field immediately. TODO: uniformly assign getter symbol to all ValDefs, stop using accessed.

This phase synthesizes accessors, fields and bitmaps (for lazy or init-checked vals under -Xcheckinit) in the first (closest in the subclassing lattice) subclass (not a trait) of a trait.

For lazy vals and modules, we emit accessors that using double-checked locking (DCL) to balance thread safety and performance. For both lazy vals and modules, the a compute method contains the DCL's slow path.

Local lazy vals do not receive bitmaps, but use a Lazy*Holder that has the volatile init bit and the computed value. See mkLazyLocalDef.

Constructors will move the rhs to an assignment in the template body. Those statements then move to the template into the constructor, which means it will initialize the fields defined in this template (and execute the corresponding side effects). We need to maintain the connection between getter and rhs until after specialization so that it can duplicate vals.

A ModuleDef is desugared to a ClassDef, an accessor (which reuses the module's term symbol) and a module var (unless the module is static and does not implement a member of a supertype, or we're in a trait).

For subclasses of traits that define modules, a module var is mixed in, as well as the required module accessors.

Phase ordering:

• Runs after uncurry to deal with classes that implement SAM traits with ValDefs.
• Runs before erasure (to get bridges), and thus before lambdalift/flatten, so that nested functions/definitions must be considered.
• Lambdalift introduces new paramaccessors for captured vals, but runs too late in the pipeline, so mixins still synthesizes implementations for these accessors when a local trait that captures is subclassed.

In the future, would like to get closer to dotty, which lifts a val's RHS (a similar thing is done for template-level statements) to a method $_initialize_$1$x instead of a block, which is used in the constructor to initialize the val. This makes for a nice unification of strict and lazy vals, in that the RHS is lifted to a method for both, with the corresponding compute method called at the appropriate time.)

This only reduces the required number of methods per field declaration in traits, if we encode the name (and place in initialisation order) of the field in the name of its initializing method, to allow separate compilation. (The name mangling must include ordering, and thus complicate incremental compilation: ideally, we'd avoid renumbering unchanged methods, but that would result in different bytecode between clean recompiles and incremental ones).

In the even longer term (Scala 3?), I agree with @DarkDimius that it would make sense to hide the difference between strict and lazy vals. All vals are lazy, but the memoization overhead is removed when we statically know they are forced during initialization. We could still expose the low-level field semantics through private[this] vals.

In any case, the current behavior of overriding vals is pretty surprising. An overridden val's side-effect is still performed. The only change due to overriding is that its value is never written to the field (the overridden val's value is, of course, stored in the field in addition to its side-effect being performed).

TODO: Java 9 support for vals defined in traits. They are currently emitted as final, but the write (putfield) to the val does not occur syntactically within the <init> method (it's done by the trait setter, which is called from the trait's mixin constructor, which is called from the subclass's constructor...)