Support weakly typed data attributes

[longquanzheng]

Basically skip the type checking for those cases to be more flexible. In some case that user want to implement an dynamic workflow that may need dynamic data or search attributes (especially with persistence locking)

Another idea is to let user define data/search attribute with type by prefix:

DataAttributeDef.createByPrefix("UserInteger-", Integer.class)

[longquanzheng]

Also need #180

[zklgame]

Data attributes can be easily supported.

But search attributes need to be registered into the namespace, how could it be dynamically created during running time?

[zklgame]

To support the createByPrefix for data attributes, we could:

1. add a new filed isPrefix into DataAttributeDef.
2. in registry, add a new Map<String, Map<String, Class<?>>> dataAttributePrefixToTypeStore field to record the prefixes seperately, so that when validating the keys, the time complexity could be O(N), where N is the count of prefixes.

@longquanzheng What do you think?

[longquanzheng]

To support the createByPrefix for data attributes, we could:

1. add a new filed isPrefix into DataAttributeDef.
2. in registry, add a new Map<String, Map<String, Class<?>>> dataAttributePrefixToTypeStore field to record the prefixes seperately, so that when validating the keys, the time complexity could be O(N), where N is the count of prefixes.

@longquanzheng What do you think?

That looks good to me. I would probably do the same way as you described

[longquanzheng]

Also I just realized that getAllDataObjects will be broken for now after this change. We may just add a comment for this behavior as edge case. (In fact, I think this API is not too important to have anyway)

[zklgame]

Data attribute support in #189.