- When NDEBUG is defined that shall be honoured.
- When RUBY_DEBUG is defined that shall be honoured.
- When both are defined and they conflict, warnings shall be rendered.
- When nothing is specified, nothing shall happen.

If __builtin_assume() is enables and RUBY_DEBUG=0, RUBY_ASSERT(expr)
will be compiled to __builtin_assume(expr) and compiler can assume
expr is true and apply aggressive optimizations. However we observed
doubtful behavior because of compiler optimizations, we introduce
new macro RUBY_ASSERT_NOASSUME to disable __builtin_assume().
With this macro, we can try without __builtin_assume().

Co-authored-by: 卜部昌平 <shyouhei@ruby-lang.org>

Assertions in header files slows down an interpreter, so they should be
turned off by default (simple `make`). To enable them, define a macro
`RUBY_DEBUG=1` (e.g. `make cppflags=-DRUBY_DEBUG` or use `#define` at
the very beggining of the file. Note that even if `NDEBUG=1` is defined,
`RUBY_DEBUG=1` enables all assertions.
[Feature #16837]
related: https://github.com/ruby/ruby/pull/3120

`assert()` lines in MRI *.c is not disabled even if `RUBY_DEBUG=0` and
it can be disabled with `NDEBUG=1`. So please consider to use
`RUBY_ASSERT()` if you want to disable them when `RUBY_DEBUG=0`.

We observed combination of multiple __builtin_assume() can cause
strange compile results on clang-6 (-DNDEBUG exposed this issue).
To avoid this problem, __builtin_assume() is from clang-7.
https://github.com/ruby/ruby/pull/3120#issuecomment-630821333

Argument of RUBY_ASSERT_FAIL is already stringized message, so no
more extra stringization should be applied.

To fix build failures.

Devs do not love "3".  The only exception is RUBY3_KEYWORDS in parse.y,
which seems unrelated to our interests.