PolyInitialized annotation is needed to full express initialization semantics

See discussion at https://github.com/typetools/jdk/pull/99#issuecomment-812756239

In brief, there are some Java standard library methods that need an PolyInitialized annotation in order to full express their semantics. The easiest example is Throwable.initCause() which is commonly invoked either from within a constructor (UnderInitialization) or immediately after construction (Initialized), and returns a self reference to support method chaining. The return value of this method is currently annotated @UnknownInitialization, which means method chaining in the style of "return new Throwable(e.getMessage()).initCause(e)" is not allowed by the initialization checker, which complains that the resulting value is @UnknownInitialization.

The method chaining pattern is also commonly used by Builder style objects (ie, new Builder().setXXX().setYYY()), and thus a PolyInitialized annotation is likely to be useful for Builder objects as well, by allowing setXXX() style methods to be invoked from within constructors (useful for more complex builder objects).

Start with the linked discussion and inspect the initialization checker handling for Throwable.initCause(). Determine how PolyInitialized should express calls from both UnderInitialization and Initialized contexts, including chained construction; done means the stated chaining pattern is accepted without losing the appropriate initialization state.