Positional only argument support with Python keywords

[pekkaklarck]

Python 3.8 added support for positional-only arguments. They have some nice usages with Python code but I doubt they are that important with RF libraries. Anyway, we should support them or at least make sure things don't break strangely. I also believe we should add the support already in RF 4.0 because changes affect our model objects that may be exposed via Libdoc APIs and changes later would cause backwards compatibility problems.

This issue covers supporting positional-only arguments only with Python based keywords. Separate issue can be submitted about supporting them with dynamic libraries that often are implemented with Python and could benefit from the support as well. We could also support them with user keywords if someone comes up with valid use cases.

[pekkaklarck]

This is now done otherwise but documentation is still missing.

[pekkaklarck]

I decided to implement this so that if a keyword is implemented like

def example(posonly, /, normal=None):
    print(posonly, normal)

and called like

Example    posonly=value

the posonly argument gets a literal value posonly=value. An alternative would have been making this an error but I decided not to do that because using e.g. what=ever would also mean passing that value as-is. Never needing to escape = with positional only arguments can be considered a feature. This is nevertheless an error:

Example    normal=value    posonly=value

[pekkaklarck]

Docs are written and this issue can be considered done.

A nice benefit of adding positional-only arguments was that it allowed removing supports_named attribute from the ArgumentSpec object. It was previously used with Java based libraries because we don't see the real argument names with them and thus couldn't support the named argument syntax with them. Now these arguments are marked positional-only and that has the exact same effect. Libdoc still shows does a library support named arguments in its outputs but that could be removed. It needs a separate issue, though.