Support lint configuration via CLI flags, similarly to clippy

[obi1kenobi]

Describe your use case

If cargo-semver-checks is invoked with an option like --current-rustdoc, then no Cargo.toml manifest is used for checking. Since all lint configuration currently lives in Cargo.toml, that means no lint configuration can be specified in such a use case.

Describe the solution you'd like

Linters like clippy allow setting lint configuration via the CLI. Cargo is about to ship lints in the near future, and may have CLI flags for them as well.

Whatever solution we end up with, we should make sure it is consistent with clippy and cargo so that merging cargo-semver-checks into cargo will be easier.

Alternatives, if applicable

No response

Additional Context

It isn't clear how much value this feature would bring, and whether it's currently blocking any workflows at all.

Interested users should upvote this issue using the 🚀 emoji to signal interest, and offer more details about their use case if that use case is not already captured in an earlier comment by a prior user. If an earlier comment matches your use case as well, please 🚀 it as well.

[suaviloquence]

A couple of notes for the future:

• Because we configure two properties for each lint (required_update and lint_level), it may not be possible to use the same CLI parser schema as rustc/clippy/cargo: One option it could look like for cargo-semver-checks might be cargo semver-checks [...] --warn function_missing --minor must_use_added --major function_missing. A good set of CLI flags should be able to configure either/both of lint-level and required-update for any lint id (and if it's possible to have a concise way to specify both, that would also be good)
• It also could be possible to have a middle-of-the-road solution: to have a CLI flag like --config-path that indicates the path to a manifest/TOML file to read the config table from. This could be the Cargo.toml manifest or a special SemverChecks.toml file, but it would just be for reading the configuration, not building the rustdoc. This would be helpful in cases where the user doesn't need cargo-semver-checks to generate the rustdoc (e.g., with --current-rustdoc) but has access to the Cargo.toml manifest/can check the config file into CI, and would be easier to implement than full CLI flags if that is all that is necessary. It would make it less compatible with Cargo if cargo ends up adding CLI flags, but that can be reevaluated at that point.