Various issues around the "at-most" combinators

[nikswamy]

• One can write UINT32 t[<= n] which raises a deprecation warning saying to instead use [:byte-size-at-most instead of [<=; but, this syntax does not exist. Instead, we support only [:byte-size-single-element-array-at-most

• The semantics of T [:byte-size-single-element-array-at-most n] is that we validate the format of T and check that it fits within n bytes, and then we always consume exactly n bytes by advancing the position of the parser. So, this in effect allows one to encode an element T padded out to n bytes. However, the documentation about this feature does not mention anything about how many bytes are actually consumed. In fact, it might suggest that a variable number of bytes are consumed. We should fix the doc.

Conceptually, we could add another combinator which checks that a T is represented in at most n bytes, but consumed only exactly as many bytes as are needed to represent a T, without implicitly padding up to n. Such a combinator would inherit the the strong-prefix property of T.

• The name of the *-at-most combinators are confusing, because they suggest that a variable number of bytes are consumed, when in fact we consume exactly n bytes. We should rename them.

• One can write T x[n] and 3D issues a warning if sizeof(T) <> 1, saying use the :byte-size notation. This warning should be an error, since it's an easy mistake to overlook.