To allow C++ compilation. Fix suggested by @dearblue.

Rename new functions:

- `mrb_convert_type(mrb,val,type,tname,method)`
   => `mrb_type_convert(mrb,val,type,tname,method)`
- `mrb_check_convert_type(mrb,val,type,tname,method)`
   => `mrb_type_convert_check(mrb,val,type,tname,method)`

Old names are defined by macros (support `tname` drop and
`char*` => `mrb_sym` conversion).

The mixture causes warnings on 64 bit Windows (VC).

You can now use `NEXT` within `switch` statement like 7c087eb.

On non-`gcc` compatible environment, `NEXT` is translated to `break`.

To silence some warnings. This change cancels part of 7ef3604134.

In the past code, the current `callinfo (ci)` was modified, thus it was
possible to pop `ci` beyond the `cibase`, that could cause out of memory
bound access for the code like the following:

```ruby
def m2
  lambda {
    Proc.new {
      return :return # return from the method
    }
  }.call.call
  :never_reached
end

p m2
```

By definition `mrb_assert()` called only when `MRB_DEBUG` is defined too.
But make I wanted to make clear that the local variable `current_checkpoint_tag`
is only accessed when `MRB_DEBUG` is set by wrapping with `DEBUG_ONLY_EXPR()`.

Caused from combination of `mrb_int`, `int` and `size_t`..

It uses `mrb_str_new_lit()` internally, but it doesn't need to express
it in the name of the function (macro).

Where fixnum overflow can happen.

- Integrate `Fixnum` and `Integer`
- Remove `Integral`
- `int / int -> int`
- Replace `mrb_fixnum()` to `mrb_int()`
- Replace `mrb_fixnum_value()` to `mrb_int_value()`.
- Use `mrb_integer_p()` instead of `mrb_fixnum_p()`

As described in ISO 15.2.30.

We still have `#define MRB_TT_FIXNUM MRB_TT_INTEGER` for compatibility.

close #3123

- `MRB_WITHOUT_FLOAT` => `MRB_NO_FLOAT`
- `MRB_USE_FLOAT` => `MRB_USE_FLOAT32`

The former is to use `USE_XXX` naming convention. The latter is to make
sure `float` is 32bit float and not floating point number in general.

On some platforms, `sizeof(mrb_value) > sizeof(void*)*3`, which makes
`MRB_ARY_EMBED_LEN_MAX` zero. And zero sized array cause compile errors.

Variables in jump destination block separate declaration and assignment.

Changes made after `setjmp()` are destroyed and need reassignment.
This problem is now caused by the addition of the `OP_JUW` instruction.

When actually building on FreeBSD 12.1 with `clang10 -fsanitize=address`, mrbtest "NameError#name [15.2.31.2.1]" is failed.

However, qualifying `pc` with `volatile` slows down significantly and increases the object code.
Suppress them by qualifying only the variables that restore `pc`.

When a global jump occurs, look at the catch handler table to determine where to jump.
In that case, `pc` already shows the following instruction, but since the table shows `begin_offset ... end_offset`, the comparison is done with `begin_offset < pc && pc <= end_offset`.
If there is a corresponding handler, move `pc` to `handler.target_offset` and continue running the VM.

When a global jump across `ensure` is made by `return`, `break`, `next`, `redo` and `retry`, the extended `RBreak` object saves and restores the C-level execution position.
This extended `RBreak` can have tag information, which makes it a pseudo coroutine (the "tag" mimics CRuby).

The implementation of pseudo coroutines by `RBreak` is summarized by `CHECKPOINT_RESTORE ... CHECKPOINT_MAIN ... CHECKPOINT_END` and `throw_tagged_break` / `unwind_ensure` macros.
The restart of processing is branched by `RBREAK_TAG_FOREACH(DISPATCH_CHECKPOINTS)`.

- Not only `rescue` blocks but also `ensure` blocks are now sandwiched between `OP_EXCEPT` and `OP_RAISEIF`.

- Remove the function `ecall()`.
  It is no longer necessary to re-enter the VM to perform an "ensure block".

  This will resolves #1888.

- Added instruction `OP_JUW` (Jump while UnWind).

  It jumps unconditionally like `OP_JMP`, but searches the catch handler table and executes the ensure block.
  Since it searches the catch handler table, it is much heavier than `OP_JMP`.

`OP_PUSHERR`, `OP_POPERR`, `OP_EPUSH` and `OP_EPOP` are removed.

- `OP_EXCEPT` checks if `mrb->exc` is `NULL`, `MRB_TT_EXCEPTION` or
  `MRB_TT_BREAK`.
  If `mrb->exc` is `NULL`, it will be replaced with `nil`.

- If `OP_RAISE` is `nil`, it does nothing and the immediately
  following instruction is executed (like `OP_NOP`).
  Also, in case of `RBreak` object, it moves to the processing for
  `break`.
  With this change, the instruction name is changed from
  `OP_RAISE` to `OP_RAISEIF`.

Which is caused by `MRB_NAN_BOXING`.

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

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

- `pool`
- `syms`
- `reps`

- `mrb_convert_type`
- `mrb_check_convert_type`

Those function no longer take `tname` string representation of desired
type, and take method symbols instead of `const char*` names. This is
incompatible change. I hope no third-party gems use those functions.