Prepares to support reading binary Ion 1.1.

[tgregg]

Description of changes:

• Adds FlexUInt reading logic to IonCursorBinary. This is used to read the length of variable-length types, as in calculateEndIndex_1_1.
• Augments IonTypeID with Ion 1.1 support. These are pre-computed, so the big ugly method is not on the performance path. That said, beautification ideas are welcome.
• Enables the reader to recognize the Ion 1.1 IVM.
• Refactors test utilities that will be used by Ion 1.1 decoding tests from IonEncoder_1_1Test into TestUtils.

This will be covered by tests that will be added in future PRs as support for the Ion types is added incrementally. I've intentionally left some performance-related TODOs in the code for future investigation.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[popematt]

Could we just have an enum of the different Ion versions so that it's not possible to provide an invalid version, or are there performance implications to doing that?

[tgregg]

There are no performance implications in this test code, but it's just us writing the tests, so I don't think it's super important for us to protect ourselves from providing an invalid version to this utility.

If the question is intended to apply broadly to the source, there are some performance implications when we get into, say, branching vs. dynamic dispatch. For example, if we wanted a non-trivial enum that contained abstract methods to be overridden by each version. This is similar to how I wrote the first Ion 1.1 prototype, and I found simple branching to be much more efficient. We could have a simple enum that just enumerates the acceptable versions, but on the read side we still have to validate the version that was declared to the encoding, then map to the enum. After validation, I'm not sure if it really matters whether we compare an int or an enum value on the branches. Maybe an enum starts being more clean once we have another major version, but we're a ways off from that.

[jobarr-amzn]

An enum seems like a good idea to me.

[popematt]

There's an OpCodes class, so you could write:

Suggested change

	} else if (lowerNibble == 0x6) {
	} else if (id == OpCodes.VARIABLE_LENGTH_DECIMAL) {

...and similarly for others where it's a single value. I don't think it's any more expensive to compare a whole byte instead of a nibble, so it would be nice to do this for readability.

[tgregg]

Sure, #645