Merge improvements for innodb_lru_dump_restore.patch from Facebook

Merge improvements to innodb_lru_dump_restore.patch from Facebook. Below is the summary of changes from the corresponding MP (https://code.launchpad.net/~percona-dev/percona-server/fb_changes_auto_lru_dump/+merge/46012). In addition, an option to control page ordering must be added so it is possible to choose whether pages are loaded in sequential or LRU order.

This also fixes bug #686392 and bug #686534.

Changes:

LRU is dumped to a temporary file first to avoid partially written files
in backups or in case of a crash.

Release the LRU mutex while doing memset and file IO. Should mimimize
the impact on the host during scheduled LRU dump. Basic detection of
LRU cycling should the next page to dump be put back at the head of the
LRU during the unlocked window.

Added option innodb_lru_dump_old_pages to control whether old pages are
included in the LRU dump. The default is to only dump young pages.

Added option innodb_lru_load_max_entries specifying the maximum number
of LRU entries to restore. The default is 512k entries (8GB).
Consecutive pages are merged and only count as one, so you will probably
load more pages than this number of LRU entries.

Switched to writing out LRU in priority order.

Load in LRU priority order, but always merge consecutive pages.

Add status vars for LRU restore progress: lru_restore_total_pages and
lru_restore_loaded_pages.

Added restore rate limiting (restore no more than innodb_io_capacity
pages per second). In my testing, a value of 5000 is fine for a
pre-up-ip warmup, but this should be reduced to 500 before serving
traffic to ensure adequate IO capacity is available for foreground
threads.