Revisiting MayHoldCloseableResource

[Brian Goetz]

> This might be more straighforward changing "statically known" to
> just "known".
 > Otherwise some people will be thinking that there is some static type
 > that would tell them which kind they have, which there isn't.

OK, did that, integrating my sentence about "generality" with your 
latest, below.  I think they say the same thing but is a little harder 
to misread as "always use TWR".

> /**
>   * An object that may hold resources (such as file or socket handles)
>   * until it is closed. The {@link #close()} method of an AutoCloseable
>   * object is called automatically when exiting a {@code
>   * try}-with-resources block for which the object has been declared in
>   * the header. This construction ensures prompt release, avoiding
>   * resource exhaustion exceptions and errors that may otherwise occur.
>   *
>   * @apiNote
>   * <p>It is possible, and in fact common, for a base class to
>   * implement AutoCloseable even though not all of its subclasses or
>   * instances will hold releasable resources. For code that must operate
>   * in complete generality, or when it is known that the AutoCloseable
 >   * instance requires resource release, it is recommended to use {@code
>   * try}-with-resources constructions. However, when using facilities such as
>   * {@link java.util.Stream} that support both IO-based and
>   * non-IO-based forms, {@code try}-with-resources blocks are in
>   * general unnecessary when using non-IO-based forms.
>   *
>