use Uninitialized instead of Null without changing Predef

[olhotak]

This is an alternative to #15124 that does not depend on #15123 and in particular doesn't depend on changing Predef. The motivation is to try out Uninitialized in the compiler first before committing to a specific implementation in Predef.

This is a first step towards addressing pain point 1 in #14622. A second step would be to tweak the flow-sensitive analysis with special treatment for vars whose type is not a supertype of Null. Such a var cannot have null written into it, so once we know it's non-null, it can never become null again.

[bishabosha]

how does this relate to compiletime.uninitialized, could we instead update its meaning under Explicit-nulls? (it seems a mistake to reserve it only for class fields)

Edit: I see now that I guess uninitialised is not meant to be the unique value of a unique type (such as null), but some "default" value within the type it is assigned to

[olhotak]

compiletime.uninitialized is for fields that are not intended to be null ever when read. They are intended to be initialized before they are first read. Their type reflects this: they (can) have a non-null type, so you don't need to handle the possibility that they could be null when reading them.

Uninitialized is a type that is Null when read but non-null for writing: a null cannot be written to such a field. A type such as String | Uninitialized acts like String | Null when reading a field and therefore forces you to consider the case that it could be null.

[olhotak]

This PR should wait for #14946 to maximize places where Uninitialized can be applied.