Adds Module#< and Module#<=

e.g.
```
def m(a,(b,c),d); p [a,b,c,d]; end
m(1,[2,3],4)  # => [1,2,3,4]
```

mruby limitation:
Destructured arguments (`b` and `c` in above example) cannot be accessed
from the default expression of optional arguments and keyword arguments,
since actual assignment is done after the evaluation of those default
expressions. Thus:

```
def f(a,(b,c),d=b)
  p [a,b,c,d]
end
f(1,[2,3])
```

raises `NoMethodError` for `b` in mruby.

It can happen if signals are used (e.g. from `mruby-alarm` gem).

Because it can swallow `break` etc. if they are used in loops.

Add documentation to mrb_load_irep

Because `try_convert` method rarely used in production. For mruby users,
we have `__to_str` utility method to check string type.

We have added internal convenience method `__to_str` which
does string type check.

The issue #3854 was fixed but fundamental flaw of lack of stack
depth check along with fibers still remains. Use `MRB_GC_FIXED_ARENA`
for workaround.

The ISO standard does not include implicit type conversion using
`to_int`. This implicit conversion often causes vulnerability.
There will be no more attacks like #4120.

In addition, we have added internal convenience method `__to_int` which
does type check and conversion (from floats).

The issue #3920 was fixed but the fundamental flaw of lack of stack
depth check along with fibers still remains, even though it's not
easy to cause the issue.  Use `MRB_GC_FIXED_ARENA` to avoid the issue
for workaround.

After this patch, `obj.to_enum` raises `ArgumentError` if the object
does not respond to the enumerating method. This is incompatible to
CRuby but I think this behavior is better and CRuby should be updated
to behave like this.

The GC may occur between `sg_shift` and `mrb_assoc_new`, in which
case `key` and `value` could be freed even tough they are still alive.

The issue is found and fixed by https://hackerone.com/hexodus

The saving `pc` position should be beginning of the instruction.
But after `mruby 2.0` byte code modification, the `pc` variable
points the beginning of the next instruction. We save the previous
position in a local variable `pc0`.

Line number information in a compiled file was wrong.