`OP_LOADI Rn -0` should be `OP_LOADI_0`.

This is preparation for integer constant folding.

Explicit write barrier for binding

Output an error if the `INTPTR_MAX` macro is undefined in C++

Avoid implicit casting from void pointers for C++

When doing `conf.enable_cxx_abi` and compiling with FreeBSD + clang or MinGW, such as `INTPTR_MAX` constant macro is not defined if `#include <stdint.h>` precedes `#include <mruby.h>`.
Currently I get a warning when I use an undefined macro, but if I don't notice it I get confused in a link error.
It can be expected that the problem will be easier to understand by making a clear error.

Adding `-Werror=undef` as a compiler flag can also result in an error, but this can be a problem if the system header file itself uses undefined macros, for example.
This patch does minimal confirmation only, but has no side effects.

- OP_GETGV
- OP_SETGV
- OP_GETSV
- OP_SETSV
- OP_GETIV
- OP_SETIV
- OP_GETCV
- OP_SETCV
- OP_GETCONST
- OP_SETCONST
- OP_GETMCNST
- OP_SETMCNST
- OP_GETUPVAR
- OP_SETUPVAR

- `OP_SETGV`
- `OP_SETIV`
- `OP_SETCV`
- `OP_SETCONST`

build(deps): bump github/super-linter from 4.4.1 to 4.5.0

If `OP_MOVE` comes after `OP_GETUPVAR`, you can skip move and redirect
the destination register of `OP_GETUPVAR`.

When `OP_GETUPVAR` is generated right after `OP_SETUPVAR`, there is no
need to read the upvar back to the register, e.g.

    3 008 OP_ADDI       R2      1
    3 011 OP_SETUPVAR   R2      1       0
    4 015 OP_GETUPVAR   R2      1       0
    4 019 OP_LOADI_2    R3

`OP_GETUPVAR` at the address `015` is useless. We can skip it like:

    3 008 OP_ADDI       R2      1
    3 011 OP_SETUPVAR   R2      1      0
    4 015 OP_LOADI_2    R3

Bumps [github/super-linter](https://github.com/github/super-linter) from 4.4.1 to 4.5.0.
- [Release notes](https://github.com/github/super-linter/releases)
- [Commits](https://github.com/github/super-linter/compare/v4.4.1...v4.5.0)

---
updated-dependencies:
- dependency-name: github/super-linter
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Add a testcase of #4137 fix

build(deps): bump github/super-linter from 4.3.0 to 4.4.1

Bumps [github/super-linter](https://github.com/github/super-linter) from 4.3.0 to 4.4.1.
- [Release notes](https://github.com/github/super-linter/releases)
- [Commits](https://github.com/github/super-linter/compare/v4.3.0...v4.4.1)

---
updated-dependencies:
- dependency-name: github/super-linter
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

build(deps): bump github/super-linter from 4.2.2 to 4.3.0

Bumps [github/super-linter](https://github.com/github/super-linter) from 4.2.2 to 4.3.0.
- [Release notes](https://github.com/github/super-linter/releases)
- [Commits](https://github.com/github/super-linter/compare/v4.2.2...v4.3.0)

---
updated-dependencies:
- dependency-name: github/super-linter
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

So that the function behave consistently with `mrb_load_proc()`.

- String#__lines
- Array#__ary_eq
- Array#__ary_cmp
- Hash#__delete
- Kernel#__case_eqq
- Integer#__coerce_step_counter

Mrbgem gem_init.c: add headers for irep loading when cdump is disabled, but presym is enabled

Do not include `stdint.h` before `mruby.h`

When `disable_cdump` is declared on a Mrbgem spec, the procedure for
loading MRuby code from the gem's `mrblib` directory is slightly
different; instead of loading the mrblib code as a Proc built from the
compiled irep, the compiled irep is loaded directly. The header files
`mruby.h` and `mruby/proc.h` are needed only when the irep is loaded
directly. They are currently included only when presym is disabled, they
should be included whenever either presym is disabled *or* when
`disable_cdump` is called. The `cdump?` predicate method happens to
return true in either case (presym disabled *or* cdump disabled), so
this change should be safe.

A change in `load.c` is left uncommitted.

That means it's a method not to be included in the backtrace, for
example `raise`.