Refactor ContentController to be generic

[GuySartorelli]

ContentController is currently hardcoded to work with SiteTree. It's not uncommon to want to route to a DataObject that isn't managed in the site tree, and therefore isn't a SiteTree object - but for the frontend to treat it the same way it treats SiteTree objects.

Making this class more generic removes some friction from that use case.

Acceptance Criteria

• Make this controller work with other DataObject subclasses
• Remove methods that assume a hierarchy (e.g. ChildrenOf() which is probably barely ever used anyway)
• Remove Page() method, which is probably barely ever used and would be easy to either implement into SiteTree or for projects to implement if they need it
• Add a new config property or method to tell it what class it's supposed to handle
• Move URLSegment somewhere more generic (maybe a PageDataObject which has anything related to URLSegment added to it and is either an extension or trait applied to SiteTree, or a superclass for SiteTree)
• Add a separate config property for the class that should be used for the Menu method
  • Set this to SiteTree from whatever module contains that class
• Remove SiteConfig() method - that's provided in a global template provider elsewhere
• Change getViewer() to always (or conditionally based on config) use the base Page template, falling back on appropriately namespaced templates even for non-SiteTree
• If needed, remove assumptions that records will have the Versioned extension, or throw an exception if they don't.
• If necessary, define an interface or add explicitly hasMethod()/hasField() checks, and throw exceptions if needed fields/methods aren't available
• Either also make OldPageRedirector generic, or else only use it when SiteTree is the model being used.

TO DECIDE

Arguably this doesn't open much opportunity if we don't move some stuff around as well - but what should we move, and to where?

• Do we want to move this to silverstripe/framework?
• Do we want to move this to a new module (along with ModelAsController and RootURLController)?
• Do we want to keep these here, and move SiteTree and CMSMain to a new silverstripe/pages module?