Add support for High-Precision Numbers

[tnovotny]

If I readf the code correctly then support for High-Precision Numbers missing, or did I miss something?

[WhiZTiM]

@tnovotny, thank you for raising this issue. You are right UbjsonCpp doesn't natively support High-Precision Numbers as stated in the spec.

I will create a patch for this, however we know C++ doesn't natively support arbitrary precision numbers, which of the following behaviour should we take?

To quote the spec on different behaviors for unsupported platforms:

That said, for libraries written to support platforms that do not natively support arbitrarily large or precise values, the following guidance can be employed to provide a safe and consistent behavior when encountering them:

• [Default] Exception/Error: Throw an exception(or return an error) when an unsupported high-precision value is encountered during parsing. The platform doesn’t support them so allow the client a chance to be aware of the fact that it is receiving data it won’t know how to parse into a native type.
• [Optional] Handle as a String: (must be user-enabled) In the case where the client doesn’t need to do any processing of the value and is just doing pass-through like persisting it to a data store, treat the high-precision value as a string and return it to the caller.
• [Optional] Skip: (must be user-enabled) Provide the ability for the parser to optionally skip unsupported values during parsing. Be aware that this is a dangerous approach and will likely lead to data loss (skipped values won’t be visible to the client), but in the case where a client must be able to parse any and all UBJSON it received even if it doesn’t support arbitrarily large or precise numbers, then this has to be considered.

Skipping is not an option for me. I am likely to hand out an API for the High Precision Number as std::string (option 2). ...

[tnovotny]

Personally I think none of these are right. The stuff comes in as a string, so just keep it as string.

• [Default] Handle as a String.

I'm sorry, but throwing an exception or setting an error on legal JSON is not really an option as far as I am concerned and seems like a really really bad idea.