Consider sealing the `IonElement` interfaces in the next major version.

[popematt]

Whenever we create a new major version of ion-element-kotlin, we should discuss sealing the IonElement interfaces. The result of the discussion should be either sealing the interfaces or clearly documenting why we think it's a good idea that the interfaces are open.

[popematt]

Here are some points (both for and against) that were brought up in #88

• A user might want to create their own IonElement implementation in order to e.g. have a lazy implementation or to be able to create a view over data that is not Ion.
• It's easy for someone to implement IonElement in a wrong way.
• Users would prefer carefully constructed abstractions rather than implementing IonElement themselves.
• There appear to be places that are not designed and documented for inheritance. ("Design and document for inheritance or else prohibit it" -- Joshua Bloch.)
• If IonElement is a sealed interface, then any new implementations have to go through us (the Ion maintainers) in some form—making us a potential bottleneck for innovation.