Not from the execution ensure proc; fix #3849

You should not access `mrb->c->ci->argc` directly.

The outer class of the class/module definition should be taken from
`MRB_TARGET_CLASS(mrb->c->ci->proc)` not `mrb->c->ci->target_class`
which is the target of constant lookups.

Otherwise half-baked string object will be allocated.

Merge branch 'mrb_without_float' of https://github.com/pandax381/mruby into pandax381-mrb_without_float

Make `block_given?` to search for the top of the scope first.
The top of the scope means either:

* the top method body
* the enclosing class body
* the top-level

The special case is the method defined by `define_method` with a
block as in #3841. In cases like this, the method body (given by
a block) is not considered as the top of the scope. You need to use
`&block` in the block parameter if you want to know if a block is
given to the method.

This commit also changes the behavior of `MRB_PROC_SCOPE` flag.
Now it is only set if the `proc` is either a class body or a method
body defined in Ruby. It is no longer set for a block that given to
`define_method`.

When `block_given?` is called from a block given to `define_method`
as a method body, the `bidx` may not be within `env` saved closure.
In this case, it causes heap buffer overflow.

Also removed the code to normalize NaN value for `MRB_NAN_BOXING`.
Tha code was added to fix #1712 but no longer required after 249f05e7.

This strings in `irep` pools may be freed forcefully in `mrb_irep_free`.
This commit probably fixes #3817 as well.

don't strip away backtrace info when an exception is re-thrown

Unlike method definition, constant reference should start from
`MRB_PROC_TARGET_CLASS(ci->proc)`, not `ci->target_class`.
In addition, `MRB_PROC_TARGET_CLASS(ci->proc)` is always set.

The destination `proc` may be an orphan.

The issue #3837 is a regression of #3819. I was mistakenly removed
a important code to mark fibers from `env`.

The change is suggested by `ukrainskiysergey` in #3836.
I deleted the other line for clarity. I also updated comment lines.

This is a resurrection of d0a7e01d, which is accidentally
removed by 93f5f225; Fix #3715

This is a resurrection of 75c374ca, which is accidentally removed by
93f5f225; Fix #3507 #3512 #3518 #3521

Both `uvenv` function and `env` generation in `create_proc_from_string`
function have bugs to handling enclosed environment objects.

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`.