[Meta] Restructuring `cdh.core`/vision for 4.0

For version 4.0 I want to go further with modularization of this code-base, moving away from the monolithic approach we have now to a 'a la carte' experience.
Version 3.1 already starts this process with it's changes to dependency handling. However, restructuring the python code is going to be more involved, and is probably going to be backwards incompatible. (At least in part).

In my opinion, the biggest problem is `cdh.core`, it's very big and unfocused. I would like to reduces ``cdh.core`` to what the name suggest, a small building block that the other apps can depend on. This would make creating other apps a bit easier, as we can then still use some common tools without pulling in the more opinionated frontend code.

For example, currently the ``cdh.federate_auth`` app needs to contain some duplicate code also in `core`, to make sure it's actually standalone. (Otherwise, some people not using our frontend stuff might complain about polluting their app with unnecessary stuff).

A different, smaller, advantage is making it clearer what this app has to offer, as currently a lot of stuff is hidden in the (undocumented) mess that is `cdh.core`.

Proposed new apps:
- ``cdh.frontend``: A new app containing most of the base templating, form widgets, template tags, etc. Basically anything frontend related that also uses `uu-bootstrap`. (or: `cdh.django_frontend`, to make it more clear it's meant for apps with a mainly Django frontend).
- ``cdh.admin``: Moving the Django admin tweaks into its own app (note: name might need to change to avoid clashing with the Django admin itself).
- ~``cdh.mail``: Moving all of ``cdh.core.mail`` into it's own app~ This is actually now a thing
- ``cdh.db``: Moving the ORM fields and helpers currently in ``core`` into it's own app
- ``cdh.js_urls``: Moving ``cdh.core.js_urls`` into it's own app. It's a fork of an external repo, so it might be nicer to have it in it's own app. It's currently only used for some Vue stuff, so it really does not make sense to _always_ load it (especially as there is some overhead attached to it). And honestly it's doubtful if we really want to have this feature in the future, there are better ways to do this job.

This will leave ``cdh.core`` as significantly smaller app, with only basic helpers/utilities.

Other changes:
- Removing all custom SCSS, aside from 'bundle build files'. Currently we have some extra SCSS aside from the `uu-bootstrap` in this repo. They live here, because I thought it would unnecessarily pollute ``uu-bootstrap`` as it's _very_ focused on solving some annoying parts of Django i18n. However, some applications also add their own SCSS (e.g. FRISSER) and experience has thought me that it's very difficult to include the SCSS in this repo in the compiled bundle. So I'd like to move the SCSS into a ``uu-bootstrap-extra`` repo, which can be installed using yarn. (Making bundle creation in applications a lot easier).

Open questions:
- First off, is this the right approach for this project? Or do we want to keep the more monolithic structure we have now?
- Form widgets: Some widgets are very basic (and do not use `uu-bootstrap`, such as the 'date' widget.). These could stay in `core`, but then we'd have 2 apps that contain from widgets. I think this tradeoff is worth it, as having the HTML5 widgets in core lets us use them in apps where a dependency on `uu-bootstrap` would be overkill. However, I like to have some feedback on this.
- Libraries: where are non-python libraries going to live? Some of them should be in `frontend`, but more general stuff like TinyMCE and jQuery might be handy even if `cdh.frontend` isn't going to be used. Do we want to use `core` to contain them? It would make the static files dir a bit crowded, but I don't think that's a major issue?
- 'Transitionary version': Basically, do we want a version that contains a lot of these changes, but with backwards compatibly 'import files' with a deprecation notice? It might make the migration a bit easier, as it can be done in steps. However, migrating from DSC 2 to DSC 3 was also 'big', but aside from the FETC, didn't really pose that much of a problem iirc.

Semi-related question:
Is anyone using the `base\minimal.html` base template?

I might update this text in the future, I'll clearly mark changes and post a comment if I do.