Ensure all adapters and decorators can be extended

[victornoel]

I got bitten by #647 again so decided to make a PR directly :)

The constructors could have been made public but the EC way seems to be using the of() static method for this usage, so I left it at that.

[motlin]

I believe this is technically a security vulnerability, but I'm also kind of open to it. A malicious user could deserialize some custom bytes into a subclass of an unmodifiable wrapper that's not actually unmodifiable. On the other hand, I haven't used serialization in years and if you're security conscious, you probably forbid deserialization. It's something to think about though. We prevented subclassing on purpose at the time. The JDK wrappers do the same thing.

[motlin]

I'm looking around in Guava, and they don't even have concrete classes. Unmodifiable wrappers are all abstract.

I don't fully understand why the concrete classes must have hidden visibility, but I think it's important.

[victornoel]

@motlin in my own projects, I usually use the following pattern to solve this kind of situation:

• I have only abstract or final classes, and abstract classes have either final or abstract methods
• I have abstract "envelopes" which are classes whose sole purpose is to implement an interface, wrap an object of that interface and delegate all methods (defined as final) to the object.

With this pattern, I can define any implementation of the interfaces in terms of existing implementations. See https://github.com/victornoel/eo-envelopes for a tooling made and use to simplify my life to apply this pattern.

Writing envelopes for all the interface of EC could be a good alternative to this PR :)