Implement persistence of audit data

[jewzaam]

Once the question here is answered:

• Where should audit data be persisted?

[jewzaam]

Was thinking about this on the way to work today. The simplest thing I can think to do is make each audit a separate document in a single entity. Maybe it can be configured later. But, since lightblue will be able to talk to RDBMS soon (no date set, but it's being implemented) and there's talk of wanting this data in a relational database internally we can do that later and migrate from the old (data in mongo written by lightblue) later. So I propose:

1. Update the audit schema
2. Have audit hook call lightblue crud API to insert new data
3. q.e.d.

Originally was thinking audit hook's persistence should be independent of lightblue. The problem is I don't have any RDBMS to store this in right now. So I'd if I write it to mongo for now and move it I'd have to change the audit hook implementation. AND I'd be locking any other users of the hook to this decision and move. I think that's a bad idea and therefore the proposal to use lightblue crud API's and leave the persistence to metadata definition.

[jewzaam]

• [x] update audit schema
• [x] update audit hook implementation for schema changes
• [ ] update audit hook to call crud layer (directly or via api?)

[jewzaam]

NOTE this will not include setting lastUpdatedBy in the audit data. See #5