Improve Horizon's Data Architecture

[WIP] Just jotting down thoughts in a public space. The title is intentionally vague because I'm unsure how to phrase this, but will describe the problems below:

Problem(s):
- There is a big desire for cross-region views and controls.
- Project/ Admin is not necessarily a clear split any more.
- Most of the Django Admin Dashboard code is dependent on the Project equivalent, making disabling panels clumsy. For example, the majority of the Admin panels simply extend the Project code with an extra field or two, but this still has a separate code separation and all the respective boilerplate.

Suggested Solutions:
- Drop the "Project/ Admin" idea, and use the panel group as the top level dashboard. This way, the Admin/Project panels can be combined, and we control the data displayed on the page itself through relevant logic (policy etc). Could be as simple as toggle in each page to display data in this project, or across multiple projects/regions.
- We could have a cross-region panel group specifically for large scale async data. This may tie into multiple other efforts, like OSIC working on the overview pages and Searchlight.

Advantages/ end goals:
- Less confusion over what can or can't be done. Actions should be role based, rather than expecting a user to go a panel and then realise its the wrong panel and go to the admin version, only to then have to carry out a massive query just to create X resource.
- Less code to maintain. It seems sensible to manage the appearance of actions or queries sent by parameters, not by duplication/inheritance and redefining actions. A lot of the smaller panels have hundreds of lines of boilerplate and separation just to add an extra form field or a table column.

Other considerations:
- The angular work gives us a good avenue to rewrite this. Currently, they seem to going along the lines of '<horizon_url>/project/details/<resource_type>/<id>' for example. I'd prefer to use <horizon_url>/<resource_name>/<id> etc.