Proposal: Permit dataType equivalents for non-measure Property values

According to the [docs](https://github.com/buildingSMART/IDS/blob/development/Documentation/facet-configurations.md#properties), `dataType` is a required field when specifying a `value`.

The implication of this is that the IDS author must know the correct IFC dataType expected for a property. For IfcMeasures this is no doubt important due to Units etc, but for a lot of simple cases this constraint feels overly prescriptive.

For instance an IDS author will now need to specify if a custom property called 'Acme_Reference' has a dataType of IFCTEXT, IFCLABEL, IFCIDENTIFIER or some other [datatype](https://github.com/buildingSMART/IDS/blob/development/Documentation/DataTypes.md). If the IFC exporter doesn't follow these conventions the IDS value check will **fail**, despite the value matching, and all these IfcTypes being backed by the same EXPRESS STRING type. In any upstream service processing this IFC the property will almost certainly be treated as the same String type so it will feel like a 'false negative' to a typical user.

i.e. To all intents and purposes these are the same to an end user - despite a different semantic:

```
#10=IFCPROPERTYSINGLEVALUE('Acme_Reference',$,IFCLABEL('Bar'),$);
#11=IFCPROPERTYSINGLEVALUE('Acme_Reference',$,IFCIDENTIFIER('Bar'),$);
#12=IFCPROPERTYSINGLEVALUE('Acme_Reference',$,IFCTEXT('Bar'),$);
```

I see a couple of options:

1. Make dataType optional again (and update the Audit tool)
2. Allow some limited aliasing between dataTypes at verification

The latter would be my suggestion. My thoughts would be to allow any non-Measure dataType to be deemed equivalent if it's underlying 'Type' is the same. I'd suggest for 99% of cases this is going to types backed by 'string'. You could also make the case that dataTypes such as IfcInteger and IfcPositiveInteger are equivalent but that's perhaps a more subtle edgecase.

Any thoughts?