Since it is already set in `mrb_proc_new()`.

Now the method tables (in classes/modules and caches) keeps C function
pointers without wrapping in `struct RProc` objects. For the sake of
portability, `mrb_method_t` is represented by the struct and union, but
if the most significant bit of the pointer is not used by the platform,
`mrb_method_t` should be packed in `uintptr_t` to reduce memory usage.

`MRB_METHOD_TABLE_INLINE` is turned on by default for linux.

Instead of `irep` links, we added a `upper` link to `struct RProc`.
To make a space for the `upper` link, we moved `target_class` reference.
If a `Proc` does not have `env`, `target_class` is saved in an `union`
shared with `env` (if a `Proc` has env, you can tell it by `MRB_PROC_ENV_P()).
Otherwise `target_class` is referenced from `env->c`. We removed links
in `env` as well.

This change removes 2 members from `mrb_irep` struct, thus saving 2
words per method/proc/block. This also fixes potential memory leaks
due to the circular references caused by a link from `mrb_irep`.

fix: src\proc.c(96): warning C4244: 'function': conversion from 'mrb_int' to 'int', possible loss of data

It may be better to raise exceptions, but CRuby doesn't.

One for the receiver, the other for the block.

Fix #3356

Reported by @bouk

ref #3215

If a function (such as mrb_read_irep_file()) is declared without MRB_API
in header file (such as include/mruby/dump.h), implementation of the
function in source file (such as src/load.c) should also defined without
MRB_API.

If MRB_API is mismatch, Visual C++ reports link error with C2375 error
code: https://msdn.microsoft.com/en-us/library/5k6kw95a.aspx

mrb_proc_new_cfunc_with_env() allocates RProc with RProc::env as NULL
then allocates REnv and sets it to RProc::env of the allocated RProc. If
incremental GC is ran before "allocates REnv and sets it to RProc::env
of the allocated RProc", the allocated RProc's GC status is
"marked" (Black) and the allocated REnv's GC status is
"unmarked" (White). The next incremental GC sweeps the allocated REnv
without re-marking the allocated RProc. Because the RProc is Black and
the REnv is White.

We need to implement write barrier for the case.

We can force to cause the above situation by the following patch:

    diff --git a/src/proc.c b/src/proc.c
    index f98998f..4f4e25c 100644
    --- a/src/proc.c
    +++ b/src/proc.c
    @@ -92,6 +92,7 @@ mrb_proc_new_cfunc_with_env(mrb_state *mrb, mrb_func_t func, mrb_int argc, const
       struct REnv *e;
       int i;

    +  mrb_incremental_gc(mrb);
       p->env = e = env_new(mrb, argc);
       MRB_ENV_UNSHARE_STACK(e);
       e->stack = (mrb_value*)mrb_malloc(mrb, sizeof(mrb_value) * argc);

With this patch, "rake test" causes segmentation fault.

From the CRuby 2.2.2 Proc#arity documentation:

If the block has optional arguments, returns -n-1, where n is the number
of mandatory arguments, with the exception for blocks that are not
lambdas and have only a finite number of optional arguments; in this
latter case, returns n.

mrb_define_method setting mrb->proc_class for method proc