Keep kraken-wrapper in its own package after all, remove kraken-{core,std,common} packages completely

[NiklasRosenstein]

> Drop kraken-{common,core,std} packages entirely

With the minor upgrade we can relatively safely get rid of the placeholders for kraken-{core,std,common} because nothing explicitly depends on it, and if it does it's still going to resolve their old versions.

> Keep kraken-wrapper in its own package

Not having kraken-wrapper live in its own package has the issue that Pipx will not link it's krakenw console script into the user's script directory unless you add the --include-deps flag, but none of our documentation and what our users are used to contain that information. We could re-export the entrypoint in the kraken-wrapper package's entrypoints, but then there's not really a good reason to keep the wrapper code into the repository, especially considering that it pulls in a number of additional dependencies that you don't need in your build environment.

> Consistent Kraken usage in repository

In addition, I'm changing the repository so that all installing/formatting/linting/testing is done by Kraken as well, reusing the .kraken.py we had for kraken-std originally and had moved into kraken-build, as well as adding the docs/ directory as a subproject.

I've also update the docs/ subproject to integrate neatly with the root Kraken project (so now you can run krakenw run :docs:serve to view the docs).

> Cut changelog history before 0.20.0

Who's still interested in the changelog for Kraken 0.12.4?

[NiklasRosenstein]

The "Changelog / Insert Pull Request URL into new changelog entries (pull_request_target)" job will keep failing until it is merged because the source of the job definition is taken from the default branch.