Admin Edit class improvements

Bunch of improvements related to making less repetitive code.

Nothing that will automatically improve older code, but any new code going forward will require a lot less drudge work.

* **AdminEdit**
  * New ```isNew()``` method so we don't have to check against ```id === null``` everywhere.
* **AdminEdit** and **AdminDBEdit**
  * CS because I was there (and much of AdminObjectEdit was in AdminDBEdit to start)
* **AdminObjectEdit**
  * :metal: So much new awesomeness :metal:
  * ```initInternal()``` loads the ui from ```getUiXml()```
  * ```getObjectClass()``` requires you pass in the parent class of the primary data object you are editing.
  * ```initInternal()``` uses ```getObjectClass()``` to automagically build the data object, and does class mapping and loading for you. You do however still have to require the local class in your subclassed code.
  * ```saveDBData()``` has internal stages:
    * ```updateObject()``` - this is where you'd want to set dataobject values from the ui (more awesomeness wrt that a few bullet points down). If you call ```parent::updateObject()``` before you do any setting of values, which you should, you get:
    	* Automagic setting of createdate on new objects that have a createdate (which requires https://github.com/silverorange/swat/pull/19)
    	* Automagic creation of a clone of the old object on edits, which is added to an array of data objects to flush on successful save with the new ```flushObjectOnSave()``` method. This is for the case where an edit changes the namespace of the object and we want to flush the old namespace as well. If the object isn't modified after ```updateObject()``` is done, these don't get flushed as you'd want.
    * ```saveObject()``` which does what it says on the tin.
    * ```postSaveObject()``` where you'd run any other code you wanted, such as saving binding tables, adding to a search queue, or outputting the saved message.
    * And finally, ```flushObjectsOnSave()``` which flushes all the objects that may have been added by ```flushObjectOnSave()```
  * Copy ```assignUiValuesToObject()```, ```assignUiValueToObject()```, ```assignObjectValuesToUi()``` and ```assignObjectValueToUi()``` from **SiteEditPage** for quick, convenient and consistent ways to move values between the UI and the dataobject.
  * And create further convenience methods ```assignValuesToUi()``` and ```assignUiValues()``` which assume the values are being set on the primary dataobject, which they are 99% of the time.

This still needs documentation, but I wanted some feedback first, both on structure, and general naming of things.

I'd prefer the naming of **AdminObjectEdit** and it's internal methods such as ```getObject()``` to be AdminDataObjectEdit, ```getDataObject()```, etc - but we use the *Object* shorthand in **SiteEditPage** and I wanted to keep it easy to remember the method naming patterns between the admin and front end pages on sites.

This came out of a [silverorange/Rap](https://github.com/silverorange/rap) admin bug, where we wanted to flush older versions of the data object being saved when it was not a new object, and there was no good way to do it without repeating a lot of code per local Edit page.

There will be a Rap PR showing off how much code this reduces soon, which I'll reference here.