Add JSON<->ROS message serialization/deserialization.

[ahmad-ra]

Enhancing the capabilities by adding support for converting JSON strings into/from ROS messages at runtime. IMO, this functionality fills a crucial gap in the ROS ecosystem, particularly for scenarios where integration with external systems like MQTT brokers is required.

The motivation behind this PR is to provide a dynamic integration mechanism similar to what is offered by the Python-based ros_bridge package, but for C++.

The core reason is to bridge ROS C++ with MQTT brokers using json payloads, dynamically casting json objects into ROS messages.

I edited mqtt_client and did PR, which depends on the updates of this package.

The mqtt_client already have a couple of open issues regarding this functionality.

Key Contributions:
-Implemented the JSON<->ROS-msg Serializer/Deserializer and added the required tests to ensure correctness.
-Demonstrated the correct integration into the existing package by adding a test of the complete cycle of serialization, deserializeIntoJson, and serializeFromJson into a ROS message.
-Most importantly, I tried my best to integrate it correctly into the code base following the same coding style, so that the code base remains homogeneous, and also insuring backward compatibility.

I believe this PR benefits ROS interoperability, and is important to the community,

[ahmad-ra]

Update: Fixed ROS2 support and updated CMakeLists

[facontidavide]

Hi,

I finally decided to look into this and I can not accept it the way it is (too many changes).
I will start adding rapidjson as a dependency, here:

https://github.com/facontidavide/rosx_introspection/blob/master/package.xml#L23

To even consider mergin a PR, it must be MUCH smaller. Let me cheery pick some of your code and we can discuss if I need anything later

[facontidavide]

I also added pre-commit and clang-format, to make sure that your future PR will not include any formatting change (that add a lot of noise!!!!!).

I would like to keep rapidjson in the private API, therefore we should not include it in ros_parser.hpp.

Better to use Pimpl idiom, if necessary (but I don't think it is?).