Batch import now overwrites where an existing record shares the same ext_id/ext_id_type
Ledger functionality added.  Now, admins can trace activity through the system.

Basic design is that, any time a change is made to the link_list table,
a row is added with the user making the change, the time, what kind of change it is,
and a serialized copy of the new link_list structure.  Because we're capturing from creation
onward, the previous version can be found by filtering the ledger for ext_id( and _type), sorting
the ledger desc by created_at, and grabbing the second record.

Serialized records do NOT have any guarantees of consistency with the schema going forward.  They are
snapshots of a moment in time - if the link_lists or links tables change, they will be invalidated.

It might be a good idea to compare the most recent schema timestamp with created_at if and when
user-controlled deserialization is implemented.
Display user actions, configured time zone (environments probably should be exemplars someday soonish)