Move tagcloud out of core

Fixes #7140 

Tested and all components still work (tags page handler, sidebar tagclouds and theme preview component)

/cc @ewinslow 

Only left the language key "tagcloud" in core as it is a generic word

TODOs:
 - [ ] Move `css/tagcloud/site.php` to `elgg/tagcloud.css`
Apologies. I didn't mean to come across harsh, hence the winky face in my previous comment. I agree this is extremely unclear ATM. Glad we're having this discussion so we can clear things up. Thanks for working with me.

For CSS standards, I think we definitely want to prefix any CSS that elgg provides with elgg-*. This just ensures no conflicts with plugins or 3p software. I'd encourage ColdTrick to do the same. E.g. cold-*. The prefix in this case is based on vendor, not plugin. That is necessary because of 3rd party CSS from outside. Plugin names may not be sufficiently unique to provide a proper namespace against such CSS. This is not a hard and fast rule, but generally I'd avoid naming things based on plugin name if I can come up with a more general name. 

The idea with the view location is that I'd want to put each logical CSS component in its own file, rather than breaking things down by where the CSS is expected to be used. This would hopefully make it clearer how to edit for someone inspecting the CSS. If they find a class, it's more or less clear what view they need to override. Yes, search works too but once you learn the convention you wouldn't have to search so much.

Essentially I want the CSS view to be named based on the CSS component, not the plugin that defines that component. This also make them much easier to move from plugin to plugin without obscuring what they do. Overriding individual components also then becomes trivial. 

So elgg-tagcloud => css/elgg/tagcloud.css. Similarly, I'd want elgg-button to go in css/elgg/button.css. so the CSS class structure matches the directory structure. This leads to a proliferation of files, but that's sort of the point. Each file does one thing (defines one component). Buttons have several variants (action, submit, delete, cancel, special, etc). I haven't thought about whether these should each go in separate files or all in the same one. I like the idea of having them all in separate files, again just to keep each file doing one thing. But this might be overkill because I could see some of those files having only one rule...

The CSS is redundant in this case because now the filename is CSS and it's in the CSS directory, Hindsight is 20/20 and if I were doing it all over again I'd name it "assets" and put all static assets in the same subdirectory. But all views used to end in php and we never thought of doing foo.css.php, so a CSS directory prefix seemed like the most logical option.

This also makes dependencies more fine grained so we have the option of loading less CSS overall on any given page.

Admin/site distinction is a valid and confusing point, I agree. I don't have a good answer for this one. It's like we support two themes in one, which elgg was not designed to handle. I feel like anything we come up with here is going to feel strange. We had talked about having a separate viewtype at one point.

But either way I'd assume we're still naming the views based on the component they define, not the view they extend or the plugin they're a part of (with room for exceptions).