select/ignore/enable/disable is a mess

Status quo:

• ignore or extend-ignore ASYNC error codes in config is not possible, as flake8 gives an error
• when running flake8-async as a plugin, --ignore and --extend-ignore is possible on the command-line, flake8 does not seem to enforce the three-letter rule there
• select does not currently have the validation rules enabled that ignore does.
• --select and --ignore are not supported when running as standalone
• it's always possible to use --enable and --disable.
• when running as a plugin, we add individual error codes for ASYNC9xx to the default_ignored codes
• when running as standalone, we set the default of --disable to ASYNC9.

Implications:

• if running as plugin, you have to select/--select ASYNC9xx codes to enable them. Trying to enable them will do nothing.
• But if you want to default-enable ASYNC9xx rules, and disable them individually, you need to use a combination of select/--select and --disable (or --ignore on the CLI).
• if running as standalone, you have to --enable ASYNC9xx codes. --select gives errors

This is... a mess. And it feels like --[extend-]ignore on the CLI, and select could get hit with the three-letter validation rules at any point which would make it impossible for end-users to enable ASYNC9xx codes unless they downgrade flake8 / we update flake8-async.

suggestions:

1. Stop calling option_manager.extend_default_ignore
2. Always default --disable to ASYNC9
3. in parse_options, read options.select and parse out any selected ASY... codes, adding them to --enable
4. same thing with options.ignore -> --disable, in case --ignore has been used on the CLI
5. [maybe] register --select and --ignore as options when running as standalone.
   • this would make it slightly easier to switch from plugin to standalone, but the added complexity might not be worth it. e.g. flake8-async --select=ASYNC --ignore=ASYNC9 --enable=ASYNC91 --disable=ASYNC910 would be possible to write and impossible to understand. Though that's ofc already the case when running as plugin
   • we could give a warning/error if users are using both enable+select or disable+ignore for ASYNC codes though

this would achieve:

1. You can always use --enable to enable ASYNC9 codes, you're not forced to touch select/ignore
2. Even if only using select/ignore you get the speed upside of disabling visitors (although this is somewhat diminished after adding ASYNC100 to Visitor91x)

Start by reading parse_options and the calls to option_manager.extend_default_ignore, then trace how options differ between plugin and standalone modes. Compare the proposed enable/disable/select/ignore behavior against each case in the issue; done means ASYNC9xx rules can be enabled consistently without depending on flake8’s three-letter validation, with standalone option registration resolved.