Be consistent storing property variant information

[mikee47]

Issue #77 has arisen as a consequence of space-optimisation. Range information is stored in the PropertyInfo::Variant union as two 32-bit values for regular integers, but as a pointer to the information for 64-bit values. This PR fixes that inconsistency so that all range information is stored indirectly. This also reduces flash storage slightly since the size of this union is reduced from 8 to 4 bytes. The Range for all properties are now defined in the parent object definition.

In addition, the PropertyInfo metadata structure has been refactored to include a specific Range type definition for each property type. This allows further simplification and clarification of the python script.

[mikee47]

Continuing from #81 (comment), I feel there may be value in adding some trySet_xxx methods. The name implies that it will attempt to set the value, but if it fails then the data remains unchanged:

if (!updater.trySetSimpleInt(1000)) {
  // Value is out of range, deal with it
}

Note that an update can also fail if the underlying store is opened read-only. However, that check only needs doing once when the updater instance is obtained.

Note: This does not apply to strings since they require additional storage allocation, so if that is exhausted the method will fail, and the string value will be set to the default. In this case, a trySetString method would fail without changing the existing value.

Also, in PR #79 since the range is exposed in the parent object we can do:

if (updater.simpleIntRange.contains(1000)) {
  // OK, value in range
  updater.setSimpleInt(1000);
} else {
  // Value out of range, handle the exception
}