Support sending DynamicDataAdapter sample via dynamic writer

[sonndinh]

• Move the internal XCDR serialization functions for DynamicDataImpl out of its DataContainer. DataContainer now is just a container of the sample data which would facilitate serializing to other formats.
• Add new interfaces for XCDR serialization to DynamicDataBase that allow dynamic writers to send dynamic samples constructed from DynamicDataAdapter in addition to DynamicDataImpl.

[jrw972]

Keep going. We intended to move all serialization-related code out of the container and the DynamicDataImpl. The "to_xcdr" function should take a DynamicData, Serializer, and whatever else is necessary. With a free function, the same code can serialize either a DynamicDataImpl or a DynamicDataAdapter.

 @iguessthislldo 

[sonndinh]

Keep going. We intended to move all serialization-related code out of the container and the DynamicDataImpl. The "to_xcdr" function should take a DynamicData, Serializer, and whatever else is necessary. With a free function, the same code can serialize either a DynamicDataImpl or a DynamicDataAdapter.

 @iguessthislldo 

The serialization code for DynamicDataImpl was written to work specifically with the data container in that class. If we move it out of DynamicDataImpl, we'll need to provide a way to access the data container, e.g. via a public getter, but I think we don't want to let end user uses that interface too. Another way I can think of is making the "to_xcdr" function a friend of DynamicDataImpl. But this approach seems a bit clunky to me since many of the serialization functions called by it also need access to the data container as well.

It doesn't look like we can reuse the same serialization code of DynamicDataImpl for DynamicDataAdapter. Since the internal data of DynamicDataAdapter is a C++ value of the corresponding type, can we just use the generated operator<< from type support for it?

[iguessthislldo]

A lot of the code below is can be simplified by making full use of RefWrapper. Here's one example:

OpenDDS/dds/idl/marshal_generator.cpp

Lines 1607 to 1612 in 4d1d6a3

	} else { // sequence, struct, union, array
	RefWrapper wrapper(type, field_type_name(dynamic_cast<AST_Field*>(field), type),
	prefix + "." + insert_cxx11_accessor_parens(name, is_union_member));
	wrapper.nested_key_only_ = wrap_nested_key_only;
	wrapper.done(&intro);
	return indent + "serialized_size(encoding, size, " + wrapper.ref() + ");\n";

It will make some decisions based on the type and others based on traits set before calling done.

[sonndinh]

RefWrapper is already used for types that need IDL::DistinctType. The names with _forany suffix are manually constructed because RefWrapper will generate references (I think this is needed by marshal_generator) while I need to get non-reference types to instantiate values for them. I think it's simple enough to construct those type names manually without needing to change RefWrapper.

[mitza-oci]

The function definition can use const here, just not in the header. I think there's a note on this in the gudelines, and if not then we can add one.

[sonndinh]

The guidelines have a related guide (https://opendds.readthedocs.io/en/latest-release/internal/dev_guidelines.html#language-usage, point 6th) but it doesn't explicitly say when to use const.

[sonndinh]

I updated the guidelines for this.