This is follow up of 62554ca9

Deprerecated constants which had been warned since 2.4.

Instead of letting callers rescue the error always.

* renamed argument `writable` as `waiting`
* hosited out creating and raising exception
* turned into a `switch`

Just cast down explicitly.

The user management on Android seems very different

https://rubyci.org/logs/rubyci.s3.amazonaws.com/android28-x86_64/ruby-master/log/20200416T234122Z.fail.html.gz

This is a follow-up of 83240f31 .

It seems gcc prior to 5 suffered from preprocessor bug.  We have to
provide workarounds.

See https://github.com/ruby/ruby/runs/591138012

----

Here is something interesting.  According to C99, strictly speaking,
the gcc behaviour was in fact legal(!) and everything else were
wrong.  This was not a bug of gcc, rather a bug of the ISO C Standard.
This defect was reported to the committee as DR#412, and fixed
accordingly.  All tested compilers now conform C17's updated
preprocessor description.

See http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_412.htm

FreeBSD's <sys/cdefs.h> is broken.  Cygwin is also affected by that.
We need to avoid using them.

See also:
https://github.com/freebsd/freebsd/commit/d1c67819db000c02d3a9c79f3651c10aeedad1a0
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;f=newlib/libc/include/sys/cdefs.h;h=44d6d53977e6bc82c2b1e6dbe8ae7f310b260604

Instead of SignalException for SIGPIPE, raise `Errno::EPIPE` with
instance variable `signo` and re-send that signal at exit.
[Feature #14413]

Similar to rb_syserr_fail_path, but just returns the created
exception instance instead of raising it.

With compiling `CPDEBUG >= 2`, `rb_iseq_disasm` segfaults if this
table has not been created.  Also `ibf_load_iseq_each` calls
`rb_iseq_insns_info_encode_positions`.

The same bug as 8355a998 existed in attr_reader too.

We started to use fastpath on invokesuper when a method is not refinements
since 5c276818, but we shouldn't have used fastpath for attr_writer either.

`cc->aux_.attr_index` is for an actual receiver class, while we store
its superclass in `cc->klass` and therefore there's no way to properly
invalidate attr_writer's inline cache when it's called by super.

[Bug #16785]

I suspect the same bug also exists in attr_reader. I'll address that in
another commit.

`arg_rhs` has the same check and is always a non-void value
expression.

MJIT_CC seems not defined
https://ci.appveyor.com/project/ruby/ruby/builds/32161572/job/u5sw8yn4in87heki

https://github.com/ruby/date/commit/9968eb69f0

We tried to fix this like https://github.com/ruby/ruby/pull/3029, but it
didn't work. The failure has never been helpful for developing MJIT, and
currently it's not prioritized to be fixed. Until we try to figure out
the root cause on AppVeyor vs120, let's optionally disable testing when
the random corruption happens.

The vm1_ prefix and vm2_ had had special meaning until
820ad9cb and
12068aa4. AFAIK there's no special
meaning in vm3_ prefix.

As they have confused people (like "In `benchmark` what is difference
between `vm1_`, `vm2_` and `vm3_`"), I'd like to remove the obsoleted
prefix as we obviated that two years ago.

Often it is easy to search, grep, etc from command line, for
debugging purpose.