Please make sure that the new code passes the unit tests, e.g. the code style checked by uncrustify.

The PR adds the API as well as the storage of the parameters to the node class directly. In the future a node will also have a service / topic interface to interact with them . Let me describe a few examples why I think the implementation should be separated from the node instance:

• A node might want to use the parameter interface to store internal data (since it provides nice variant types) and wants to do that beside the "normal" parameters. Hence the node does not want to expose these internal parameters via the public service / topic interface. But without being implemented in a separate class the logic of parameters is not reusable.
• Also the aspect of parameter storage and accessor functions should be separated from the service / topic interface. A node might want to expose a set of parameters via two different service / topic interfaces: e.g. via the services set_param and set_advanced_param. Again with an implementation in the node class a custom node does not have that freedom.
• Writing a unit test for a "ParameterClass" is way cleaner and self contained then testing parameters inside of a node.

@dirk-thomas this PR does not implement the API that's exposed to developers, this just implements the internal storage for a node. This PR adds the internal structures and logic to support the public API.