* Update wrong zip-code

Just rename index in data dictionary and in InnoDB cache when it's possible.
Introduce ALTER_INDEX_RENAME for that purpose so that engines can optimize
such operation.

Unused code between macro MYSQL_RENAME_INDEX was removed.

compare_keys_but_name(): compare index definitions except for index names

Alter_inplace_info::rename_keys:
ha_innobase_inplace_ctx::rename_keys: vector of rename indexes

fill_alter_inplace_info():: fills Alter_inplace_info::rename_keys

A partial backport of 67f21fb3a077dedfd14b9ca720e926c55e682f93,
Bug#22283790: RANGE OPTIMIZER UTILIZES TOO MUCH MEMORY WITH MANY OR CONDITIONS

The backported part changes SEL_TREE::keys from being an array of
MAX_KEY elements (64*8=512 bytes) to a Mem_root_array<SEL_ARG*> (32 bytes +
alloc'ed array of as many elements as we need).

The patch doesn't fix the "not limiting memory" part, but the memory usage
is much lower with it.

Background:

  - as described in MySQL Internals Prepared Stored
    (http://forge.mysql.com/wiki/MySQL_Internals_Prepared_Stored),
    the Optimizer sometimes does destructive changes to the parsed
    LEX-object (Item-tree), which makes it impossible to re-use
    that tree for PS/SP re-execution.

  - in order to be able to re-use the Item-tree, the destructive
    changes are remembered and rolled back after the statement execution.

The problem, discovered by this bug, was that the objects representing
GROUP-BY clause did not restored after query execution. So, the GROUP-BY
part of the statement could not be properly re-initialized for re-execution
after destructive changes.

Those objects do not take part in the Item-tree, so they can not be saved
using the approach for Item-tree.

The fix is as follows:

  - introduce a new array in st_select_lex to store the original
    ORDER pointers, representing the GROUP-BY clause;

  - Initialize this array in fix_prepare_information().

  - restore the list of GROUP-BY items in reinit_stmt_before_use().