WL#2991: Provide libraries for use by storage engine developers

As part of the "pluggable" architecture, MySQL should take existing code and 
make it available as libraries that can be used by developers of storage engines 
and other plugins.

Today it is easy to create a trivial storage engine, but rather daunting to 
build one that, e.g., caches disk pages in memory or uses B-Tree indexes.  So 
possible candidate libraries include MyISAM's key buffer and a B-Tree 
implementations.  Both of these can be found in the mysys/ directory, so they 
are already good candidates to be libraries, but they aren't really usable yet.  
Most notably, they aren't formally documented. 

This task has a few major components.

1: Any candidate library code must become independent of its current context.  
The library cannot assume that it is running in any particular engine, and the 
server cannot assume that only one engine is using a library.  

2: Each engine or plugin that uses a library needs a way, independent of any 
other engines using it, to configure it (e.g. "Key_buffer_size") and for it to 
report status and statistics (e.g. "Key_reads" and "Key_read_requests").  
Perhaps this means that we need global "configuration" and "reporting" APIs.  

3: The library code must be documented for programmers.  We should publish a 
manual that contains both a reference to the APIs and examples that use them.  
This may be the biggest part of the task.  The "functions in the mysys library" 
page of the internals manual is a bare-bones beginning to this. 

4: The existing storage engines need to be maintained in a way that adheres to 
the published APIs.  Once published, the documentation must be a "living 
document" used both internally and externally or it will cease to be useful.  
Every public API (including these libraries, but also especially including the 
handler, UDF, and plugin APIs) should be given a version number and assigned to 
a particular developer who manages and maintains it.