Idea of refactoring Key PMC

Current Keys are messy and incomprehensible. So there is idea of refactoring them into something more sane.

Keys currently serve only one purpose: navigate in nested containers. Iteration over containers was removed as part of key_revamp branch. To support this functionality more implicit and in clean way we will:

1. Add KeyItem interface class to represent single abstract step.

2. Implement StringKeyItem, IntegerKeyItem, PMCKeyItem and RegisterKeyItem to store concrete value for each step. Such FooKeyItem will implement get_foo vtable methods, freeze/thaw and nothing else. We don't need FloatKeyItem because float keys are meaningless. RegisterKeyItem will store tuple register_type, register_number to reference particular register.

3. FooKeyItem will not be directly constructable by throwing exceptions from init and init_pmc

4. RegisterKeyItem will be directly constructable and implement set_integer_keyed_int method to set register_type and register_number.

5. Re-implement Key as:

1. RPA for storing *KeyItem.

1. Various push_foo vtables to create specific FooKeyItem and append it to path.

Pros

1. Keys PMC become almost equal to all other PMC in terms of handling (especially in PBCs).

2. Each FooKeyItem will have clean set of responsibilities.

3. It will speed-up keys handling slightly because we'll avoid big switch statements in each Key.foo vtable methods.

4. Run-time creation of keys will be simplified to something like

  # We are creating [42;"foo";84;"baz"] key.
  $P0 = new ['Key']
  push $P0, 42
  push $P0, "foo"
  push $P0, 84
  push $P0, "baz"

5. Making mistake in Keys creating/using will be almost impossible.

Cons

Someone will have to patch IMCC to support new Keys.