First of all, thanks for the PR! This is pretty big task to implement and I've been thinking it's too big for the already overdue RF 3.2, but including it is still possible if we can get this PR into a good enough shape. I won't have time for a full review until I have got RF 3.2 alpha 1 ready, but below are some general comments about this PR after a very quick look:

1. This PR only adds support for argument conversion. Conversion in the Variables section and also when assigning variables based on keyword return values are needed as well. Probably a good idea to get this first feature ready first.

2. I don't think we need to support syntax like ${arg: 'int'}. Just supporting ${arg: int} (space being optional) ought to be enough. I also don't see reasons why to support Python's typing style usages like ${arg:Mapping[str, int]} either. Just supporting same string names and aliases that work with the dynamic library API (Support automatic argument conversion with dynamic libraries #2068) ought to be enough.

3. Implementation looks pretty complicated. Most probably that's due to the support for formats like ${arg:Mapping[str, int]}. I think this could be done pretty easily in argumentparser.py: PythonArgumentParser already does it with Python based keywords and UserKeywordArgumentParser could probably do it with user keywords.

Hi,
If we don't need the typing style usages, the code will be simplied.
I will rework my code with your comments.

I removed typing style usages, abc types, enum and bytesstring type. The other types is already convertible by TypeConverter.
Too I put my implementation in argumentparser.py and I removed typingresolver.py.

I am closing this PR because i will propose new implementation for the issue #3278 who work with variable