Ensure Records are treated as separate namespaces for IDs

[amitchone]

Fixes a bug whereby RecordMembers with a common ID (but different parent IDs for the record) would be falsely flagged as duplicates:

struct RecordA
{
    ThingSet::ThingSetReadWriteRecordMember<TS_ID_EUI, TS_ID_RECORD_A, "eui", uint64_t> eui;
...

struct RecordB
{
    ThingSet::ThingSetReadWriteRecordMember<TS_ID_EUI, TS_ID_RECORD_B, "eui", uint64_t> eui;
...

ThingSetReadOnlyProperty<uint64_t> eui{ TS_ID_EUI, TS_ID_DEVICE, "rEUI" };

...

ThingSetReadOnlyProperty<std::array<RecordA, NUM_RECORD_A>> recordAs{ TS_ID_RECORD_A, TS_ID_ROOT, "As" };

ThingSetReadOnlyProperty<std::array<RecordB, NUM_RECORD_B>> recordBs{ TS_ID_RECORD_B, TS_ID_ROOT, "Bs" };

The above would flag TS_ID_EUI as duplicated.

This change prevents this from happening, essentially treating records as namespaces keyed on the parent ID. IDs must still be unique within a namespace, but it is now possible to have common IDs between namespaces. I.e., in the case where one device is handling several different record types from different devices.

[ethan-duckett-brill]

All looks good to me but I don't seem to be able to approve!

[garethpotter]

This is good and how it should have worked in the first place. Pleased to infer from this that you are now ingesting data from multiple device types.

[garethpotter]

What is this comment regarding?

[amitchone]

This was in regards to the alpha and beta members of the two records. Pre-this-fix, this wouldn't build, so any build failure linked to these properties is a regression

[amitchone]

Pleased to infer from this that you are now ingesting data from multiple device types.

Yes, we're at quite an exciting point now where we are working on system integration as a whole - keep an eye on this space!