Split up views_default_views cache to improve memory usage

On sites with a high number of default views, the views_default_views cache size can grow very large which increases the memory profile for every page that includes a view (see views_get_view()). One strategy to reduce this overhead is to split up the cache from a single array of all default views into individual rows containing each individual view.

This patch is a first attempt at this approach and maintains full API/backwards compatibility. This issue is generalizable and is a general problem to solve when dealing with caching defaults -- probably of interest as well for ctools and other implementers of exportables.

Applies & tested against 2.6 as well as DRUPAL-6--3 HEAD.

Some notes:

• On some basic tests on Atrium, this patch reduced memory consumption per page by about 2.5MB. The current views defaults loading process costs about 3MB on Atrium, while a load from the segmented cache is about 0.5MB.
• Why not "sync" default views to the db? We could do this, but we would need to keep track of which views are defaults and which are normal/overrides. Using cache tables for this actually made more sense as it simplifies the code required to protect user-manipulated views data. The cached default views really can be blown away without any concerns.
• Other things to address: when the cache is initially built, the array passed to drupal_alter() for altering default views is still a single unified array. It may be worth splitting this up as well to keep memory consumption altogether down to little chunks of data so that no matter how many views your sites has the memory profile remains low.