Clarify interpretation of numeric literals in tree

[eslavich]

Since all numeric literals in a YAML document are represented as strings, it's possible (and permitted by the YAML spec) to write numbers that are too large for standard numeric types, decimal literals that aren't actually representable as floating point values, etc. We should consider tightening the ASDF spec with regard to numeric literals in YAML so that all implementations agree on what a given YAML number-string actually signifies.

The current standard has this to say about numeric literals:

While it is possible to store arbitrary-sized integers as literals in YAML, not all programming languages and YAML libraries are able to read them. Therefore, to ensure portability, all numeric literals in the tree must assume that the reader has no more precision than that of a 64-bit double precision floating point number: 52-bits of precision. Therefore, ASDF libraries should refuse to write files containing integers that are larger than 52-bits.

Integers

value: 1234

• Since YAML clearly distinguishes between integer and decimal literals, should we allow integers a wider range of values?
• Should the standard require integer values to be deserialized as 64-bit signed integers?

value: !core/ndarray-1.0.0
  data: [1, 2, 18446744073709551615]
  datatype: uint64
  shape: [3]

• Since the array has an unsigned datatype, is this an exception to the previous rule? Currently the asdf Python library does not let us write out this array in inline form.

Decimals

value: 0.1

• This isn't intended to be exact 0.1, right?
• Should the standard require that YAML decimal literals be deserialized into IEEE binary64?

@perrygreenfield