Make it clearer that the `--experimental-plugins` flag disables existing plugins

[another-rex]

Couple of things that need to be done here:

• Update the usage text of the flag to mention that we are

  osv-scanner/cmd/osv-scanner/internal/helper/flags.go

  Line 172 in e28c9bc

  Usage: "list of specific plugins and presets of plugins to use",

• Update documentation to list out the default set of plugin presets we use, so people can reenabled it if they want to using and add additional plugins
• When using the flag, log out the default preset that was disabled, so it's easy for users to know which preset to re-add, and they are more aware of this behavior.

[G-Rath]

@another-rex I wonder if it would be worth adding an --extra-plugins flag, as this sounds like a pretty common situation?

[another-rex]

Yeah that makes sense, rather than forcing users to re-enable everything from scratch.

[G-Rath]

and we could rename plugins to --only-plugins too, to make it clearer

[G-Rath]

actually @another-rex I'm now thinking it might be cleaner if we make this the default of plugins, and either have a special default preset that you can pass to disable-plugins or a new --no-default-plugins.

That way we won't have to deal with "what if you provide both --only-plugins and --extra-plugins"

[another-rex]

Yeah, I like the --no-default-plugins flag. Having the default plugins enabled was how some people I asked to use this flag assumed it worked as well, so this would make sense.