Pre-draft: A conda technical specification

While working on `conda-libmamba-solver`, we tried hard to maintain backwards compatibility with the classic solver, but getting 100% the same behaviour proved to be tricky. One of the reasons is that it's difficult to separate what is supposed to be a "expected behaviour" from an "implementation detail".

There are some foundational principles for that behaviour that can be found across comments, issues, PRs and other contextual metadata, but there's no detailed specification for what should happen under X circumstances.

I'd like to start a discussion around the need of standardising the behaviour of `conda` as a CLI tool and the outcomes of a number of actions. Such a document should allow us to clearly answer to questions like:

> Given a fresh Python 3.7 environment, should `conda install numpy=*=*py39*` update the Python version implicitly or should the user also add `python=3.9` to the list of specs?

Spec'ing these things out would allow the community to have a wider view of `conda` actually does (and you'd be surprised to learn how many implicit variables are part of that process), and what future iterations of the ecosystem should do instead. For example, I'd like to see how feasible is to steer the logic towards more explicit behaviour.

Topics to discuss include:

* Scope of the spec: which parts of conda need standardisation?
* Programmatic enforcement: can we create a tool agnostic test suite?
* Command-line interfaces: do we want to have a single CLI standard across tools?

This doesn't mean we need to tackle all of those issues in a single CEP. Actually, using several could be beneficial.