Version management #1: introducing pavexc

[LukeMathWalker]

What's wrong

For Pavex to work as expected, the version of the CLI used when compiling a project with cargo px [...] must match the version of the pavex library crate used in the project.
Currently, there's no mechanism to ensure this is the case. As a result, you'll get version mismatches, resulting in confusing errors (see @m1guelpf in #131).
The problem is even worse if you have multiple Pavex projects, each using a different library version: you'd have to juggle multiple CLI versions on your own since they can't all be in the PATH.

The solution

To eliminate the problem, this PR reworks the pavex CLI: it is now a version manager.
All the meaty functionality (server SDK generation, project generation) is moved into another binary, pavexc (pavex compiler).
pavex introduces the concept of toolchains, in the same vein of rustup. There can be multiple toolchains installed and it'll pick the most appropriate one for each command:

• For new, it'll check the default toolchain. If none has been defined, it'll use the corresponding version of pavexc.
• For generate, it'll match the version of pavex (the library) used in the project. If the corresponding pavexc toolchain is not installed, it'll be installed on the fly.

Missing pieces

The pavex CLI needs to grow a few commands to manage toolchains: pavex toolchain default set, pavex toolchain default show, pavex toolchain list and something for removal.
Since they are only relevant for pavex new, that's deferred to a later PR.