Refactoring LeftAndMain, CMSMain, and related classes

[GuySartorelli]

We often subclass LeftAndMain just to get controllers routed in the admin section, and then hide them because they're not actually left and main sections.
There's also a lot of code in LeftAndMain, CMSMain, and related classes that implies these were intended to be more flexible than they are in practice.

These classes have been evaluated in a spike and discussed in an internal architecture discussion and many areas for improvement have been identified.

Note

This is a Zenhub epic. The associated issues will only be seen as linked to this card if you're using Zenhub

Primary benefits of this work:

• Cleaner architecture for admin/CMS controllers
  • Less duplicated code and templates
  • More standardisation in many areas (e.g. search/filter, toasts, form submission are all subtly different in ModelAdmin vs CMSMain)
• Less effort required to bootstrap controllers of all types that are used in the CMS
• SiteTree and CMSMain are demystified
  • Can manage other data objects the same way SiteTree pages are managed (e.g. taxonomy terms manages in a hierarchical tree structure)
  • Can outright replace "SiteTree" concept with custom data objects, or have custom data objects behave "like" SiteTree pages
  • Currently lots of duplication between ModelAdmin/Gridfield and CMSMain that we can reduce
• Potentially allows making GridFieldDetailForm a little more standard, using the same sorts of controllers used for everything else and reduces duplication in that area