Define FawltyDeps version 1.0 requirements

[mknorps]

Let's use this issue to find together conditions that need to be met to release FawltyDeps 1.0.

The SemVer documentation says:

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
5. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

FawltyDeps has been stable for some time now and we developed in a way that the API does not change.

To summarize discussions with @jherland and @zz1874:

@mknorps

For me one basic requirement is that it does not produce error messages, but gracefully informs user of the failure. For that I would like to see how FD behaves on a large number of projects (one of the motivations behind the PyPI experiment).
To put it in quantifiable measures:
Testing on X data science projects and Y regular projects (let's take PyPI, but being there is already some measure of code quality):
we have no failures of FawltyDeps
FawltyDeps correctly identifies undeclared and unused dependencies for Z% cases.
X and Y should be large numbers, like ~1k. I would like Z to be 95%, but this might be more complicated with the namespace packages.

@jherland

v1.0 can mean different things to different projects, and for some it might mean nothing at all. Just looking at other Python linters (with which we'd like to compare FawltyDeps), there are projects that are definitely more mature than us, but that is not yet at v1.0 (e.g. ruff), and there are projects that use a different versioning scheme altogether (e.g. black is using a date-based YY.M.x version number).
What does v1.0 mean to us?
I'm not sure, but one of the items on our roadmap that I think would make sense to put in place before v1.0 is a documentation website.
Otherwise, there will always be bugs or feature requests that could justify delaying v1.0, but at some point we just have to say enough is enough, and do it.

[jherland]

Now that we have users asking for Conda support, we might want to consider if that is something we want to support in v1.0?

One factor in that discussion is that Conda is more "different" than the other packaging/dependency declaration methods, and that this might necessitate deeper changes in FawltyDeps, by which I mean changes that would change our API (command-line or otherwise).

(I'm hand-waving a lot here, as I don't know the details yet...)