Introduce access paths as an intermediate step between the (old-style)
optimizer plan and the iterators. Access paths (also known as iterator
blueprints) currently correspond 1:1 to iterators, in that an access
path contains pretty much exactly the information needed to instantiate
a given iterator.

In itself, the insertion of access paths does not enable anything new
in the optimizer. However, it is a stepping stone for multiple future
changes:

 - The new join optimizer will output access paths, so it is a natural
   stepping stone. (The structure has been backported from that worklog,
   although somewhat modified.)
 - Offers a simpler structure to parse to storage engines that need to modify
   or otherwise parse the plan, such as NDB join pushdown or RAPID.
 - The access path tree can be modified easily in a way that iterators
   cannot. For instance, NDB can choose to modify the access paths
   if it wishes, to e.g. rewrite a hash join to nested loop if it
   needs to.
 - Similarly, some larger-scale analysis is simpler when we can see
   and modify the tree before we instantiate iterators; in particular,
   rowid handling (for weedout) and PFS batch mode becomes somewhat less
   involved, and there are now a few situations involving hash join
   or BKA where we can use PFS batch mode where we couldn't in the past.
 - Costs and row estimates, which are purely meant for planning and
   EXPLAIN, has been moved out of the iterators. (On the more
   ambivalent side, this moves EXPLAIN code out of the iterators
   they explain.) The same thing goes for the JOIN pointer that was
   used only for EXPLAIN.
 - QEP_TABs are much less important in certain iterators, which is also
   a preparation for the new join optimizer. It is still used for
   InnoDB row buffers, though.

The changes to PFS batch mode (see above) makes for a few test changes.

Iterators are now constructed lazily; for EXPLAIN, only access paths
are constructed, and query blocks now never own iterators. Table access paths
(formerly table iterators) are no longer constructed for all tables ahead of
time, but on-demand like all others.

We propagate cost and row estimates through iterators in some more places,
since it's easy to do so and we now use them more aggressively when
constructing hash join iterators (so it's more important to have them
available).

Change-Id: I4abb610ef93d726186e914f4d31dd8e6a069fde4