[Meta] Restructuring cdh.core/vision for 4.0

[tymees]

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.