gcc 14 for aarch64 with `-O3` may emit a false positive warning for a
pointer access of `RB_BUILTIN_TYPE` called from `RB_TYPE_P`.  `Qfalse`
shouldn't get there because of `RB_SPECIAL_CONST_P`, but the optimizer
seems to ignore this condition in some cases (`ASSUME` just before the
access doesn't seem to have any effect either).  Only by reversing the
order in `RB_SPECIAL_CONST_P` to compare with 0 first does the warning
seem to go away.

```
../../.././include/ruby/internal/special_consts.h:349:36: error: conversion to ‘VALUE’ {aka ‘long unsigned int’} from ‘int’ may change the sign of the result [-Werror=sign-conversion]
  349 |     return RB_SPECIAL_CONST_P(obj) * RUBY_Qtrue;
      |            ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
```

C extension maintainers can now compile with this warning option and
the Ruby header files will generate no warnings.

[Feature #20507]

Since https://github.com/ruby/ruby/pull/6599, RUBY_IMMEDIATE_MASK also
overlaps RUBY_Qnil. Now RB_SPECIAL_CONST_P seems confusing since both
RB_IMMEDIATE_P and RB_TEST check for RUBY_Qnil while we only need to
check RUBY_Qnil besides RUBY_IMMEDIATE_MASK. I'd like to make this
change to make it less confusing.

I confirmed that this doesn't change the number of instructions used for
the RUBY_Qfalse check on Linux x86_64 GCC and macOS arm64 Clang.

Co-authored-by: Daniel Colson <composerinteralia@github.com>

Upper bits than the least significant 4 bits need not be 0.

Must not be a bad idea to improve documents. [ci skip]