String table to support byte code

The byte code representation of a type doesn't record strings within the byte code itself, instead the strings are assumed to be recorded in a separate table, as an array of ConstStringZ. The strings are UTF-8 encoded null-terminated strings.

The byte code references a string using a 16 bit index into the associated string table.

Consider the following reflected types:

namespace ns
{
    $model+ Point
    {
        float64 x;
        float64 y;
    };
    $typedef+ string8 Name;
    $typedef+ xmap PointSet;
}

The reflection of PointSet requires a byte code representation of the type xmap<Name,Point> which in turn requires a string table for the fully qualified names ns::Name and ns::Point:

//### $typedef+ ns::PointSet
namespace ceda { XTarget* Ceda_Core_Object_exObject_GetXTarget(); }
namespace ns
{
    void _Register_PointSet()
    {
        static const ceda::octet_t PointSet_type[] =
        {
            0x51,0x22,0x00,0x00,0x20,0x01,0x00
        };
        static ceda::ConstStringZ PointSet_stringTable[] =
        {
            "ns::Name",
            "ns::Point",
        };
        static const ceda::ReflectedTypedef PointSet_typedef =
        {
            "ns::PointSet",
            PointSet_type,
            PointSet_stringTable
        };
        cxVerify(ceda::RegisterReflectedTypedef(&PointSet_typedef,ceda::Ceda_Core_Object_exObject_GetXTarget()) == ceda::NSE_OK);
    }
} // ns

The byte code is {0x51,0x22,0x00,0x00,0x20,0x01,0x00} and is interpreted as follows:

Octets	Meaning
0x51	FT_MAP
0x22	FT_TYPEDEF
0x00,0x00	uint16 in little endian which is index #0 into the string table (i.e. index of "ns::Name")
0x20	FT_CLASS
0x01,0x00	uint16 in little endian which is index #1 into the string table (i.e. index of "ns::Point")