Revisit components APIs

[Voiteh]

• Creator API cannot handle invariant type parameters
• Creators won't be able to be findable using new Hashing algorithms it is bound to Matcher
• Resolver API always requires Matcher

[Voiteh]

There was an idea to create components using builder in some kind of like Validx has been using type parameters. The idea is not to create "generic" types perse so Converter<Integer,String> would be just Converter. Internally the provided types from Builder would be held and matched against if needed in Component class in some kind of Descriptor.

For example HashMapCreator

value hashMapCreator=Component.builder.parametrized.twice((TwoParametersBuilder<One,Two> builder) => builder.creator(() => 
...
}).build;

I don't think we can do such thing as there is no ability to constrain type parameters in such manner. so One would need to be constrain with given One satisfies Object

---

There is another proposition. There could be an internal API called Router. Routers would take part in finding of components. So before the whole finding algorithm would go on Routers would be matched against destination type declaration. If router would match, it would instantiate related Components with type parameters applied by reflection (clazz.memberApply...). Those components would be held till end of convertx.convert function execution for given convertion. In future it could be cached to improve performance (probably caching should be enabled through configuration of given Router). This approach would require that components are "provided" by type declaration rather than instantiated by the user itself, this would enforce thread safety of configurable components itself.