Make module wildcards more useful (requires a switch to `argparse` in `configure.py`)

For a while we can use wildcards for module selection. However, the interaction between --enable-modules and --disable-modules isn't very intuitive. For instance, I would assume that --disable-modules=pcurves* --enable-modules=pcurves_brainpool256r1 should disable all pcurves modules except brainpool256r1. That's not true though, because "disable" takes hard precedence over "enable". It is easy to turn that precedence around, but then --minimized-build --enable-modules=pcurves* --disable-modules=pcurves_secp256r1 doesn't work as expected.

Personally, I would expect that these selection switches build on top of each other from left to right. I.e. generic (de)selection followed by specific counter-selection should always apply the specific selection on the generic one.

Examples (not the current behavior!):

--minimized-build --enable-modules=pcurves* --disable-modules=pcurves_brainpool* -> all pcurves except the brainpool ones --disable-modules=pcurves* --enable-modules=pcurves_generic -> disable all pcurves, except the generic one --disable-modules=*avx2 --enable-modules=sha2_avx2 -> disable all avx2 extensions except the one for SHA-256

... for that, we need to know the order in which these CLI switches appeared during command line parsing. To the best of my knowledge, this can't be easily done using the "optparse" python module. But using "argparse" and custom action= overrides this could be achieved.

... this is really a "nice to have" feature, but something that would improve the maintainability of wildcard module selections in downstream applications. Because it makes them more robust against changes in the available modules. Perhaps something for Botan4 (#4666)?