[Code Cleanup] Removed the APP_DB_DRIVER constant, since it's no longer used.
* [CHD-2955] [Performance/Cache/Plugins] The full cache of extension properties was being cleared every time any property changed, which created some extra database traffic.  This happened often during scheduler /cron jobs.  Properties are now cached per-extension, so the invalidation of a cache has no impact on extensions that didn't change.
* [Cache/Performance/Platform] New cache engines can now be added through plugins.  Caches improve the performance of Cerb by avoiding expensive database queries for content that hasn't been modified.  Previously, only caching in the filesystem and memcache were supported.  As before, objects are cached to the local filesystem by default without requiring any special configuration.  Unlike before, the minimal set of 'bootstrap' caches required by the Devblocks platform are now always cached in the filesystem even when other cachers are available (e.g. plugins, extensions, global settings, tables, and classloader).  This makes it possible to gracefully fail to disk-based caching if a previously configured plugin is no longer available, without introducing continuity issues.  This also makes it possible to configure caching in a much more usable way from the browser in Setup, and to store cache configuration information in the platform.  The cache-related settings in the framework.config.php file are no longer used and may be safely removed.  If you were using memcache, you'll need to enable it again.
[Code Cleanup]
* [Performance/Cache/Platform] The platform-managed settings of each plugin are now cached individually.  This allows a plugin to invalidate its cache without requiring the settings of all other plugins to be reloaded from the database.  The settings for the 'devblocks.core' plugin are always cached in the local filesystem, so they're available as the platform is starting up.  This is where settings are stored for cache engine extensions (which can't load their settings from themselves, before they are set up).
* [Cache/Performance/Platform] Server-side caching is now configured in Setup->Configure->Cache.  Previously this had to be configured from the framework.config.php file, and only the filesystem and Memcached was supported.  The cache engines provided by plugins show up here.  When configuring a cache engine, its settings are tested before they are saved, and any configuration errors will be reported in the UI.
* [Cache/Platform] When content is cached by Cerb in the local filesystem in storage/tmp/, they are now named "cache--*" rather than "devblocks_cache---*".  This is mainly aesthetic, but some cache engines do have a slightly higher memory cost for longer key names.  Many filesystems have file name length limits around 255 characters.  Additionally, the shorter prefix means that files can be distinguished from each other after fewer characters.
* [Cache/Security] When objects are cached to the filesystem, permissions no longer include 'world-readable' (in Unix parlance, they are chmod 0640).  This helps prevent other users on the server from reading their content (Cerb still really shouldn't be installed in a shared hosting environment).
* [Platform/Plugins] It's very common for JSON objects to be saved as plugin settings.  The 'DevblocksPlatform::setPluginSetting()' and 'DevblocksPlatform::getPluginSetting()' methods now support an additional argument for automatically encoding and decoding JSON-based settings.  This saves some redundant code when those settings are loaded or used in multiple places.
* [Cache/Performance/Memcached] Memcached-based caching has been implemented as a plugin.  It is configurable from Settings->Configure->Cache.  The host, port, and key prefix can be set.  A key prefix provides a way to namespace keys so that multiple applications can use the same Memcached datastore.  A single host:port pair should be set, and a distributed setup should have multiple services placed behind a consistent hashing proxy like Twemproxy.  This is a way more reliable way to provide highly available services, as opposed to handling them in the client (i.e. Cerb).
* [Cache/Performance/Redis] Redis-based caching has been implemented as a plugin.  It is configurable from Settings->Configure->Cache.  The host, port, auth, database number, and key prefix can be set.  Auth is optional, and useful for publicly hosted Redis databases (like Redis-to-go); although ideally Redis should be configured on an internal IP and be placed behind a firewall.  The database number should be left blank when using a proxy in front of Redis, as many don't support multiple databases (and always use number zero).  A key prefix provides a way to namespace keys so that multiple applications can use the same Redis datastore.  A single host:port pair should be set, and a distributed setup should have multiple services placed behind a consistent hashing proxy like Twemproxy.  This is a way more reliable way to provide highly available services, as opposed to handling them in the client (i.e. Cerb).
* [Performance/Worklists] When a worklist has only one page of results with fewer rows than the paging limit (e.g. 6 rows out of 10), then an extra database query will no longer be executed to compute the total rows.  The total records is simply the number of results on the first page.  The extra query generally wasn't expensive in most cases, but it could potentially have run thousands of times per day on a moderately busy system.
6.7-dev checkpoint