Consider adding a checklist / lints of best practices

[Susurrus]

Right now there are several checks done by cargo publish. Unfortunately there isn't a concise list of the necessary requirements for publishing a crate. The only way to tell is cargo publish or cargo publish --dry-run. The latter is harder to discover. And once you detect and error, it could take a while to fix (like if you're using unversioned dependencies).

There are also higher-level best-practices that could be described to the user that they should follow. Ideally all of these would be checkable via lints within cargo itself. Some examples:

• Check that there isn't a use_* feature where * is an existing crate name with underscores (from this issue)
• That the crate has a std feature if this crate could expose functionality that made sense in a no_std environment.

Ideally this would be something that would be part of the publishing process for the first version of a crate and then could also be part of cargo publish --dry-run as a check in the future. I don't know if cargo checklist is a good name for this or it could all be contained within the cargo publish command.

[dwijnand]

cargo doctor or (better yet) cargo self fix?

[epage]

Once we have #12235, we are looking to expand the cargo-focused lints. Seems like this would be a good issue for tracking that effort.

btw there is a separate proposal for cargo doctor in #9341 but that is more of a self-check for cargo to see if there are problems.