Do we really want StringTypeWithConstraints everywhere?

[enikao]

#1096 introduced StringTypeWithConstraints, and it's now effectively the type of any IETS3 string.
This leads to several issues in our project:

• Everywhere we're testing for StringType we also need to test for StringTypeWithConstraints
• In Typesystem, we cannot test for StringType type equality anymore, need to test for subtype
• I haven't really measured it yet, but it feels like we have both a serious memory overhead (additional contents in temporarily created type nodes) and CPU overhead (e.g. from replacement rule checkStringConstraint)
• We have a field with a default value. If the default value is e.g. A, no other string is compatible with the field's type (inferred from its default value).

Is this worth the advantages? Maybe we could introduce a switch whether to support constrained types?

[alexanderpann]

I guess we should introduce an extension point to be able to go back to the old behavior. As a workaround, you should be able to create a new inference rule for StringLiteral in your language with overrides set to true and set the type back to the old string type.