* [Setup/Mail/Filtering/VAs] The Setup->Mail->Filtering page now shows the mail filtering behavior from all global Virtual Attendants on a single page.  Previously, it was only possible to have a single global Virtual Attendant and its use was implied on this page.
* [Setup/Mail/Filtering/VAs] When an admin views the Setup->Mail->Filtering page for the first time, Cerb will offer to create the first global Virtual Attendant if one doesn't exist already.  This improves the onboarding experience.
[Code Cleanup] Renamed some scheduler jobs to improve clarity.
[Virtual Attendant/Profiles] Implemented the 'owner' property on Virtual Attendant profiles.
[Virtual Attendants/Performance/Cache] Implemented a server-side cache for Virtual Attendant records.
* [Virtual Attendants] Virtual Attendants may now be disabled, which treats all of their behaviors as being disabled.  These behaviors will not trigger during events, and will now show up as macros on profiles.  This makes it very simple to simultaneously deactivate related behaviors, which was tedious in earlier versions.  Additionally, a worker can disable a Virtual Attendant while building and testing its behaviors.
[Code Cleanup/Custom Fieldsets] Tweaked the DAO_CustomFieldset::get() method to use the server-side cache.  This reduces needless queries against the database in some situations.
[Virtual Attendants/Reports] Updated the Virtual Attendant Usage report to be compatible with VA-owned behaviors.
* [Activity Log] Activity Logs for actor profiles (address, worker, group, virtual attendant) now display entries where the record was either an actor or a target of the activity.  Previously, the log only showed actor activity for those records, and target activity for everything else.  This meant that when viewing an address's activity from its profile, you wouldn't see log entries for when that address replied to conversations (as an actor), only when workers performed actions on that address (as a target).  This change provides a more comprehensive view of the activities a record was involved with.
* [Activity Log/Groups] Group profiles now display an Activity Log tab.
[Translations] Added translation strings for 'Custom Field', 'Custom Fieldset', and 'Custom Fieldsets'.
* [Virtual Attendants/Custom Fieldsets] Virtual Attendants can own custom fieldsets, providing them with long-term storage for arbitrary data on any record.  This enables some very interesting new automation workflows.  For instance, a monitoring Virtual Attendant can remember the last time it notified each worker about something by using a custom fieldset with a date on worker records.  Similarly, a sales Virtual Attendant can keep track of its progress through an automated sales process with a custom fieldset that it saves on opportunities.
[Code Cleanup/Custom Fieldsets/ACL] When a custom fieldset isn't editable, its peek will go into read-only mode.  This allows custom fieldset worklists to display more records a worker isn't able to edit.
[Code Cleanup] Added permalinks the owner column in VA worklists
[Code Cleanup]
* [Virtual Attendants/Macros] Application-owned Virtual Attendants can now create custom behaviors for any record type.  This allows global macros that are accessible by all workers, which greatly simplifies many workflows.  Previously, these macros could only be created by VAs owned by groups, roles, or workers.
* [Virtual Attendants/Macros] Implemented a 'Custom virtual attendant behavior' event.  This is the ideal place to implement generic behaviors that don't rely on a specific record type.  For example, a Twitter Bot could schedule a recurring behavior to look for new @mentions, and it wouldn't make sense to target this behavior to any particular record.  Previously, we had recommended to bind these generic behaviors on worker records just because it made them easy to manage from a profile.  Now we recommend that these behaviors be migrated to Virtual Attendant profiles.
6.5-dev checkpoint