Type hints: basic usage to infer argument types

[neithere]

Look at #107 and see what can be implemented quickly.

[neithere]

MVP:

• add support for str, int, float (and their deprecated aliases: Str, etc. until we drop support for Python 3.8 around Q4 2024)
• deprecate or just drop support for the old mechanism (if possible, move it to a policy, like with name mapping).

Nice to have:

• nargs=ZERO_OR_MORE:
  • list[str] → nargs=ZERO_OR_MORE, type=str
    • (same for list[str] | None, list[str | None] and list[str | None] | None — there's no difference for us in the context of mapping).
• nargs=N
  • foo: Tuple[str, int, float] -> add_argument('foo', nargs=3)
    followed by (e.g.) args = parser.parse_args(); args.foo[1] = int(args.foo[1]); args.foo[2] = float(args.foo[2]) (Type hinting ("typing" module) #107 (comment))
• Choices:
  • foo: Literal['one', 'two', 'three'] -> add_argument('foo', choices=['one', 'two', 'three']
    possibly with completion (later). (Type hinting ("typing" module) #107 (comment))
• Passing add_argument() params via hints instead of @arg:
  • Annotated[x, ExtraParams(type=some_callable, help="something", nargs="+")]

[neithere]

Not doing the following:

• Tuple[T, ...] — not sure how to support mixed nested types, AFAIK argparse only allows one type. Maybe limit to uniform? But that also needs to be validated, etc.
• Annotated[T, ...] — definitely must have, but Annotated was introduced in Python 3.9, so using it will require dropping support for Python 3.8. While we don't need to wait until EOY 2024 with this, it's good to at least ship whatever works before cutting support for the sake of an enhancement.