BSON support

[julian-becker]

It would be great to have BSON included support in this great JSON library!

Motivation:
I recently encountered the need for it at work, where we are already using this library for JSON processing (for many diverse purposes). Recently, we have been developing applications leveraging the rosbridge (configured in BSON mode) for communication between devices. If we can cover the BSON support with the same JSON library we are already using this would be much preferred over introducing a new library into the mix.

First Prototypical Implementation:
Actually, I have already started a quick, prototypical implementation for BSON serialization and deserialization, and if you feel BSON-support should become part of the mainline, it could be used as a starting point, and I'd be willing to help with the implementation.

Open Questions:
There is a certain fundamental format mismatch between JSON and BSON such that not all JSON values can be mapped 1:1 into BSON and vice versa.
Before continuing with an implementation, it should be clarified how these conversions should be handled (e.g. BSON timestamps, BSON 128-bit wide floats, or "naked" JSON-values which are not objects)

[nlohmann]

I had a look at BSON before, but struggled with the absence of a 1:1 mapping between JSON and BSON. Right now, we already have some issues with MessagePack and CBOR which both support binary values (see #1129 for a recent issue), but I think we can be pragmatic there. What I would like to avoid is adding support for very specific types such as timestamp or UUIDs and rather focus on those values supported by JSON.

I did not find the time to look at your implementation. Once I have a rough idea, we should continue the discussion. And of course, PRs are welcome.

[nlohmann]

I head a look at the prototype - very nice! It's a pity that BSON uses little endian and the other formats big endian. So I guess we may need to add a parameter to the existing read/write number functions to avoid having two functions.

I think it would be best if you could open a PR. Then we can shift the discussion related concrete code examples to reviews there.

[julian-becker]

Great, thanks for the welcoming feedback! I will do a little consolidation on the code and will open a PR within the next few days, and we can discuss the details there.

On a more general and long-term note regarding the support of binary formats, I was thinking maybe it would make sense to have a more 1-to-1 mapping between the serialized and deserialized form: So, instead of deserializing BSON-data directly into the nlohmann::json, it could make sense to have a proper nlohmann::bson which supports BSON fully and allows for a non-lossy roundtrip conversion of the data (similarly a nlohmann::cbor and nlohmann::message_pack). If the client then still desires to have the data in a nlohmann::json, we could provide corresponding projection functions (which could be parametrized/templatized such that the client has more explicit control over what happens with the cases that don't map 1-to-1 naturally between JSON and the other formats).

[nlohmann]

I can understand the idea of the 1-to-1 mapping, but I'm afraid this very specific usecase adds a lot of complexity to the code base. Let's first focus on basic BSON support.

[ayounes-nviso]

Can this BSON support be the basis to support CBOR byte string #1129 ?