Create some way to ease migration from IonValue to IonElement

[popematt]

Right now, converting between IonValue and IonElement requires making a deep copy of the data. The computational cost of converting the data might be too high for some users to even consider using IonElement if they are already using other libraries that handle IonValue.

Some possible solutions are:

• Create a read-only view of IonValue that can also be implemented by IonElement.
• Create an implementation of IonElement that is a thin wrapper around IonValue. Conversion simply becomes wrapping and unwrapping.

[popematt]

Here are some more thoughts about possible solutions.

• IonElement implementation that wraps IonValue—essentially a shallow wrapper around IonValue that lazily creates IonElement wrappers for child values as they are requested. Eventually, this could be equivalent to a full conversion, but it delays until it's actually necessary, and it can perform some operations (such as serialization) without requiring any conversion.
• Create an IonValueView—a super-interface of IonValue that does not have expose any mutating methods or references to things like IonSystem or SymbolTable or the parent value. IonElement can (probably) implement that interface.
• Create ImmutableIonValue—a parallel implementation of interface of IonValue (just no mutations). This helps to solve the problem of IonValue being immutable, but it does not necessarily facilitate migration to IonElement. Also, if an IonValue is immutable but maintains a reference to its parent value, then it can never be reparented. You always need a fresh copy that is cloned directly into a new parent container.
• IonValue implementation that wraps IonElement—this seems impractical to me because of the need to maintain all of the parent references, but they could be lazily created, much like the IonElement wrapper around IonValue.
• Create interfaces IntoIonValue/IntoIonElement. Rather than accepting IonValue or IonElement, libraries could accept IntoIonValue or IntoIonElement. This could make it easier for libraries to work with both IonValue and IonElement, but it might have a circular dependency problem.