Which is caused by `MRB_NAN_BOXING`.

Introduced `MRB_NO_METHOD_CACHE` which is inverse of `MRB_METHOD_CACHE`
that should be enabled intestinally. In addition, the default cache is
made bigger (128 -> 256).

The minor versions should be upper compatible. So mere opcode, section
addition can be done without breaking compiled binary.

- no OP_EXT_ anymore
- OP_LOADI16 in right position

[ruby-bugs:15921]

They are included from `mruby.h` anyway, and including it ahead can
cause some errors regarding `INT32_MAX` etc. with C++ compiler.

This combination is too hard to support. Difference between C and C++ is
too big with VisualC++. GCC and clang are OK.

- `MRB_64BIT`: the size of a pointer is 64 bits
- `MRB_INT64`: the size of `mrb_int` is 64 bits

Type `mrbc -S -B<init> -o<outfile> <rbfiles...>` to generate the C
source code that holds compiled `mrb_irep`.

Appending the following code to the bottom of the generated code,
`mruby` executes the compiled code:

```C
int
main()
{
  mrb_state *mrb = mrb_open();
  struct RProc *p = mrb_proc_new(mrb, &init_irep);
  mrb_vm_run(mrb, p, mrb_top_self(mrb), 0);
  mrb_close(mrb);
  return 0;
}
```

Eventually static compile should use this representation, instead
of `uint8_t` array that holds `mrb` data, so that we can skip
interpreting `mrb` data.

We no longer need 4 bytes alignment after we moved to the byte oriented
instructions.

Changes:
- `pool format is completely replaced
  - supported types: `STR`, `INT32`, `INT64`, `FLOAT`
  - `FLOAT` may be replaced by binary representation in the future
- insert `NUL` after string literals in `mrb` files
- `irep->pool` no longer store values in `mrb_value`
- instead it stores in `mrb_pool_value`
- less allocation
- `mrb_irep` can be stored in ROM

That stands for "local variable information".

But we need more work:
- recursive `irep` dump (`irep->reps`)
- pool values dump (`irep->pool`)