This adds quite a lot of information though, because we send many
strings.

Before: 20686 characters.
After: 55345 characters.

Theoretically we could do better, and send information about existing
imports only once as well, so when the user continues typing in a
single file, without touching imports, we don't send any new data
about imports (maybe just a confirmation that it is still the same).
But I'm not sure if this is a worthwhile optimization.

Actually, even included suggestion sets have similar property - they
don't change for a given file, unless there are changes to other
libraries which we might want to include.

This includes:
* accepting null values like sdk-summary or .packages (which are not used when building kernel for the sdk itself)
* allow enabling language experiments
* only exclude-non-sources on the non-incremental code path if that's requested

This improves the missing class, mixin, and extension method body
error messages and lays the groundwork for improving other
missing body error messages such as switch statement, finally clause,
and others.

When performing type substitution, there are three types involved, the
substitution site (`this` in TypeImpl.substitute2), the type we are
replacing (`parameterType` in TypeImpl.substitute2), and the
replacement type (`argumentType` in TypeImpl.substitute2).

Previously, we only handled the nullabilities of `this` and
`argumentType`. This CL adds support for the possibility that
`parameterType` might have nullability "*". This happens because
TypeParameterElement.type returns a star type, so for instance when
subsituting `int` for `T` in `List<T>` to form `List<int>`, we are
actually substituting `int` for `T*` in `List<T*>`.

During outline building the token stream was split after every field
initializer needed for top-level type inference. Since the token
stream is a doubly-linked list it's also necessary to split the token
stream before the field initializer in order to possibly collect the
unnecessary tokens.

These builders have some unused generality: they have an unnecessary
type parameter and the implementation classes have unused fields. As
currently used, they could be replaced with an int but the class is
kept in anticipation of adding behavior (compiling annotations).

In DEBUG mode during AOT compilation MetadataHelper::SetMetadataMappings
may spend considerable time verifying that node offsets are sorted
in kernel metadata. The problem is that there are a lot of MetadataHelpers
created (several per each compiled function).

This change moves verification of kernel metadata mappings to
the kernel loader, so it is performed only once per kernel program.

This type is equivalent to the existing type `Null`, but we need it
anyway because `Null` can only be accessed via the type provider, and
there are circumstances where we need to create this type and don't
have access to the type provider.

It also may prove beneficial to be able to distinguish between `Null`
and `Never?` in diagnostic messages.