Fix concurrency issue in constructor.

Before:
sColors served as the branch to initialize all member variables.

Subsequent calls to the constructor after sColors had been initialized,
would result in the use of static members that were not yet initialized.

Now:
We guard each reference with an explicit null check during construct.

Members that require synchronized initialization were put into a small synchronized
method.

This was chosen instead of AtomicReferences, and instead of double checked locking,
because -- although verbose -- we can tolerate a small number of overwrites to
each member variable (they are idempotent within the Application scope), thus avoiding the need for any one thread to wait/acquire a lock, as well as avoiding the need to import the Atomic library (which added no incremental benefit).

It is assumed that the JVM will not garbage collect overwritten references to
member variables that are still in use across instances of LetterTileDrawable.
This shouldn't matter because the references are volatile, anyway.

Initialization-on-demand was not available due to the use of non-static
resources on construct.

Bug: 63143138
Test: No. Old unit tests.
PiperOrigin-RevId: 160696979
Change-Id: Ie17a29e48f91cb3df07d81d29b6428b70fb4408a