feat: allow usage of '-u' flag with commands

[hunterhogan]

Description

Enhancement to the invoker that allows the use of the '-u' flag before or after commands, enabling users to forward usage requests more flexibly. This change affects the command dispatching logic and includes new tests to verify the functionality.

Checklist:

• I have followed the Contribution Guidelines
• I have added test code and data to prove that my code functions correctly
• I have verified that new and existing tests pass locally with my changes

The same 31 tests fail on my system before and after this change.

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation

[skef]

I think all of these subcommands support -h but they don't all support -u, which makes this change a little flakey.

[hunterhogan]

I think all of these subcommands support -h but they don't all support -u, which makes this change a little flakey.

Quite right.

I think all of these produce an error on afdko <command> -u:

1. buildcff2vf
2. buildmasterotfs
3. checkoutlinesufo
4. completion
5. makeinstancesufo
6. otc2otf
7. otf2ttf
8. otfautohint
9. otfstemhist
10. ttfcomponentizer
11. ttfdecomponentizer

I tried to think of an extra clever solution that could be implemented only in "invoker.py," but I didn't come up with anything.

Right now, if -u is in the second position, the user always gets an error.

>afdko -u otc2otf 
Error: Unknown command '-u'
Run 'afdko --help' for usage.

>afdko -u tx
Error: Unknown command '-u'
Run 'afdko --help' for usage.

One idea is to treat the out-of-place "-u" the same as "--help".

    if subcmd in ('-h', '--help', 'help', '-u'):

But, it might be better to reject this updated PR, because

• the error message will train the users to put the options in the correct order, and/or
• this small change might not be worth the effort, and/or
• y'all might want to design a universal solution for a misplaced "-u".

I don't have a recommendation for y'all. :/

[skef]

Wouldn't the clever solution be to maintain a set of the names of those tools and swap in -h for -u when calling one of them?

[hunterhogan]

Wouldn't the clever solution be to maintain a set of the names of those tools and swap in -h for -u when calling one of them?

Well, if the list were dynamically generated, then that would be perfect. I couldn't think of a way to do that.

If the list were static and had to be updated, then it would be helpful to the users, but more work for the maintainers.