Swaps the order of the exponent and coefficient components of decimals

[tgregg]

Description of changes:

• Swap the order of the coefficient and exponent components of the decimal encoding in binary, making exponent (as a FlexInt) come first, and coefficient (as a FixedInt) come last. Exponents are likely to remain small (and in languages like Java, are unsupported outside the range of a 32-bit signed integer), while coefficients may be arbitrarily large. Using a Fixed subfield for the coefficient reduces the amount of work that needs to be done to get to and from the big-endian representation of the value (as is required in some languages; see Java's BigInteger) from reverse-and-shift to just reverse. Note: this also retains the same component order as the Ion 1.0 encoding.
• Reclaims 0x6F, no longer using it as a special case for zero (or negative zero) coefficients. Instead, proposes that an implicit coefficient component of 0 (represented by coefficient component with width 0) represents the coefficient 0, while an explicit coefficient of 0 (represented by the FixedInt 0) represents a coefficient of -0. This allows decimals of length 15 to be encoded using the opcode 0x6F, while retaining a compact encoding for coefficients of 0.

Alternative considered:

One downside of the new order of decimal components is that integer-value decimals (other than 0d0) require one more byte to encode because an exponent of 0 can no longer be encoded implicitly. It is possible, instead of reclaiming 0x6F for length-15 decimals as proposed here, to use 0x6F to encode decimals with implicit exponent 0. However, this has the drawback of increased complexity, as the coefficient would have to be a FlexInt, requiring the reverse-and-shift logic for arbitrarily large values that the other changes in this PR propose to avoid. Discussion on this topic is welcomed.

---

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

[zslayton]

Another alternative: the set of built-in macros is not finalized, but we've often discussed having a make_decimal macro that took two variable-width integers: the coefficient and the exponent. If we follow through with that, it becomes trivial to define a macro like this:

(macro int_to_dec (x)
    (make_decimal x 0))

This macro can cost a single byte to invoke and as little as a single byte to write out the int value, making it as efficient as having a purpose-built opcode to achieve the same.

[popematt]

That's a good point, Zack. I think that fully mitigates any concern about integer values being enlarged by the proposed change.