* [Cache/Memcached/Platform] The Memcached cache engine now generates a unique key prefix every time the cache is globally cleared.  This effectively namespaces keys so that old keys will become inactive and be automatically cleaned up.  This is proxy- and multi-tenant friendly since the 'flush' command is never used.  Objects are now given a default time-to-live of 24 hours to help facilitate this.  This approach enables a lot of dynamic content to be cached without concern over exhausting the available memory (e.g. searches, records, worklists).  The unique prefix is stored in Memcached, and the automatic namespacing is cluster friendly.  If the prefix is lost for any reason (expired, or Memcached restarts) then a new one will be generated automatically and content will be re-cached by Cerb as it is retrieved again.
* [Performance/Virtual Attendants] Previously, the target record of a Virtual Attendant event (like "New mail received by group") was always pre-loaded before the behaviors ran.  Even though the behaviors efficiently shared the same record while running, this was still inefficient when no behaviors existed on the event point, because the data was still loaded anyway.  The target record is now only "lazy loaded" from the database when it is first requested (which means at least one active Virtual Attendant behavior is watching the event).  This change sped up the email parser by 200-300% during development profiling, and it should improve the performance of everywhere VAs are used in Cerb.
[Code Cleanup/Cache] Renamed $lifetime to $ttl for consistency.
* [Performance/Virtual Attendants] Virtual Attendant 'contexts' (the available fields and labels of a related set of records) are now cached in-memory for the duration of a request.  This is particularly efficient in the parser, where the same VA behaviors might run hundreds of times in one /cron request.  These contexts generally don't take long to build, but there is no reason to repeat that process hundreds of times when the cost of temporarily storing them in memory is negligible.  This mainly saves CPU cycles.
6.7-dev checkpoint