Emit an error for a forward reference to a global script-mode variable
that is likely to be unsound. This handles cases where the variable is
stored, and the reference is made at the top level before the
declaration. Such uses would otherwise have likely read uninitialized
memory. 

The only way such a reference could have been used in a sound way is
by also initializing it before declaration, e.g:

```
x = 1
print(x)
let x: Int
```

But source compatibility testing has shown this to be incredibly rare,
testing across both the source compat suite and internal Swift
projects at Apple has only turned up a single case so far.

Uses within closures and functions are unfortunately more common so
cannot be outright banned, but we will emit a warning on them.

Note that this checking doesn't help with cross-file cases, ultimately
we still need to properly fix script-mode variables such that they are
consistently treated as either local or global variables. Such a
change will be quite source breaking though, this patch at least
allows us to diagnose the majority of cases in the mean time.

### Why not diagnose in SIL?

SILGen already emits `mark_uninitialized` and `mark_function_escape`
instructions for script-mode variables which allows use-before-init
to be diagnosed by DefiniteInitialization, however this only works
when the use actually follows the declaration. In principe we could
adjust the SILGen here to emit these mark instructions at the start of
`main`, which would let us more precisely diagnose _only_ the unsound
cases. However the fact that we allow these forward references is also
generally problematic in Sema, e.g:

```
print(a)
guard let b = 3 as Int? else {}
let a = b
```

This currently crashes the compiler since the forward reference to `a`
kicks lazy type-checking, which type-checks the statement condition.
This then results in us attempting to type-check the condition
multiple times. Such code would already be invalid if in a local
context such as a function. In principe we could defensively guard
against these cases, but I would rather just eliminate them entirely.

Forum post to follow.