Add asset priority & use AssetMaker for global backend assets

[bennothommo]

This PR changes the global backend assets that were originally specified directly in the "head" template for the Backend, and uses the AssetMaker to load them instead. This should allow people the ability to manipulate the assets if need be through events.

To ensure that the global assets are loaded first before all others, I have also introduced a priority order value for assets. It may be specified by providing the second argument for addJs(), addCss(), etc. as an array and populating it with the following:

$this->addCss('my.css', [
    'build' => 'core',
    'order' => 50, // must be an integer
]);

The default order for all assets is 500.

CSS and JS assets can also be set to be preloaded by adding a preload value set to true. This will ensure that the appropriate preload tag is included with the asset.

[LukeTowers]

The "priority" property should probably be called "order" and have a default value of 500, as that is what the backend menu and permissions registration already does.

The current implementation makes these global assets a responsibility of the skin, so I'm not sure how I feel about them being included in the base controller class; thereby forcing them to be included in every single backend skin.

[bennothommo]

@LukeTowers we can add a parameter to the Skin class that defines whether to load the global assets or not - thereby making it the responsibility of the skin to load all necessary assets?

Alternatively, the skin itself could be the class that provides the global assets, although this might take some refactoring for the base skin.

[LukeTowers]

Hmm, I think I have a better idea, let's just add in those assets dynamically in the layout file itself since that's where they're used anyways. Different layouts have different global assets, so I don't really like having it be defined in the controller or the skin.

[bennothommo]

So basically just can this PR because that's what was done originally?

[LukeTowers]

The point of this PR would be to pass those assets through the AssetMaker trait (instead of manually rendering them as script / style tags) so that their attributes can be controlled through the event system (thus removing the cfasync attribute from the core as you wanted and moving it into the cloudflare specific plugin).

[LukeTowers]

@bennothommo idea was along the lines of

$this->addAssets([...])

in the layout files instead of directly rendering the asset tags; thus forcing them to go through the AssetMaker trait and associated events. Any thoughts?

[bennothommo]

@LukeTowers are we still going to implement ordering / prioritising with that? I can't quite recall the reason I did this PR (might've had something to do with the backend skinning or the widgets). I imagine it was to enforce some scripts / styles loading before other global scripts / styles, but it might be misleading if the assets are placed directly in the layouts or partials.

I think we'll have difficulty using the addAssets/Jss/Css methods directly in the layout too, because the assets would need to be prepared and collated before hitting the layout in order to be placed in the proper position in the layout. We'd effectively need to run two passes on the layout - first to get all the assets requested, and the second to place them in the head.

[LukeTowers]

Yes, I'm fine with the ordering / prioritization changes staying. I don't think we'll have to do any extra passes on the layout because we can dynamically add them exactly where they're being added right now, which is right before the call to makeAssets(), so I don't see any reason why it wouldn't work.