strip modules for SkyPy release

[ntessore]

This PR temporarily strips out modules that are not part of the upcoming SkyPy release.

Each module is removed in a separate commit, so this PR should not be squashed. After this PR is merge, we will create individual module/MODULE_NAME branches that revert one commit each. These branches will continue development of the modules for the next SkyPy releases.

Where necessary, we should be able to simply point currently open pull requests to the new branches once they are created. This might require an update of the PR branch but since stripping and each reversion happens sequentially, that should require minimal intervention.

[Lucia-Fonseca]

I have checked the documentation and all looks good there.

Q: why should this PR not be squashed after merging?
Q: Is the idea to do something similar to the second diagram here ?
Q: if this affects the future work flow, should we update the contribution guidelines?

[ntessore]

Q: why should this PR not be squashed after merging?

In our commit history on master, we want to have the commits for each module to show up. That way, we can make individual "module branches" that each revert a single commit (and it will specifically say "reverted commit xyz" in the message). If we squash the commits when merging this PR, then there will only be a single commit with all changes, and we cannot have simple revert commits for each change.

Q: if this affects the future work flow, should we update the contribution guidelines?

Not that I can think of, no. We might want to add a description of the process for adding new modules, and the fact that they are merged into release/master once they are "complete", in a second step.

[rrjbca]

Marking this as a draft for now while I test it and other possible solutions locally

[ntessore]

Module branches should be named module/MODULE_NAME to prevent issues if someone still has local refs to the previous develop branch around.