#155 Allow overwriting of brand colors in flavours

[mwehr]

Adds overwrite of brand colors for flavours.

[abias]

Hi @mwehr ,

many thanks for this PR!
I admit that the review has been pending too long and I am really sorry about that. But I have now finally had the time to review it.

Generally, your solution approach is spot-on and the code is fine. You have correctly adopted the Moodle core concept to allow themes to manipulate the styles URL into Boost Union.

Anyway, I have made several adjustments to better align the code with the existing codebase and to further improve the feature.

In detail, I have done these changes in my "Review changes" commit:

• Squashed all 4 commits into one and rebased the PR onto the latest main branch
• Raised the theme version in version.php and fixed the upgrade step in db/upgrade.php
• Better aligned flavours/css.php with /theme/styles.php (which was used as boilerplate obviously)
• Fixed a bug with the parameters of the theme_styles_get_filename() function and re-added the routine to delete theme outdated sub revisions.
• Renamed flavours/css.php to flavours/styles.php for more consistent naming.
• Add a warning to the flavours settings page that the feature won't work when slasharguments is disabled (the slasharguments setting is planned to be removed in Moodle 5.0 by https://tracker.moodle.org/browse/MDL-83378, but until then we have to respect it).
• Rename the global $flavourid variable and add some comments to it as I agree with the approach, but it still feels hacky.
• Added a 'look_' prefix to the new database table fields
• Moved the overriding of the background image in the SCSS stack process chain closer to the place where the background images are added.
• Removed the MUC caching from the theme_boost_union_get_flavour_config_item_for_flavourid() function. You have used the flavours cache which already exists in Boost Union and which is a session cache (which means that it is user-dependent) but not an application cache (which you would need for storing the flavour settings). From my point of view, theme_boost_union_get_flavour_config_item_for_flavourid() does not need to cache anything in MUC as it is just run during the SCSS generation time. And if it should cache something, this would have to go into a dedicated application cache which should then be properly invalidated when the flavour settings change.
• Add more headings to the flavour editing form
• Add a "Pre SCSS" setting to the flavour as well
• Removed the added colorpicker class as there was already an mform colorpicker element in Boost Union, it was just not located in the classes folder yet. I moved it into the classes folder and adopted the colorpicker validation rule (which is a really good idea) from your colorpicker into the existing colorpicker.
• Allow the SCSS code validation to pass even if a CompilerException occurs. Otherwise, you would not be able to use SCSS variabled in the SCSS code. This is done similarly in the admin_setting_scsscode class.

In addition to the review of your PR, I went ahead and did the following:

• Solved a small SCSS order glitch in Fix the order in which all the pre SCSS assets are added to the SCSS stack #788.
• Add some documentation to explain the SCSS stack order in the README.
• I created a follow-up issue on Improvement: Add more flavour settings which require SCSS #789 to add some more flavour settings which require SCSS

I have pushed my changes to your PR branch and will now continue to write some Behat test which cover the new functionality.

Cheers,
Alex

[abias]

The tests are red, but this is only because the PR contains the $theme->settings substring which is forbidden normally but correct in this page.

So the PR can be merged now.