Add a new pre-defined macro called OTP_RELEASE that will expand
to an integer being the OTP version. Thus, in OTP 19 the value will
be the integer 19.

The OTP_RELEASE macro is particularly useful in order to have
different source code depending on new language features or new
features in the type specification syntax. Those features are only
introduced in major versions of OTP.

To be truly useful, the -if preprocessor directive need to be
implemented. That is the purpose of the next commit.

Code that will need to work in both OTP 18 and OTP 19 can be
structured in the following way:

-ifdef(OTP_RELEASE).
%% Code that only works in OTP 19 and later.
-else.
%% Code that will work in OTP 18.
-endif.

Libraries or applications that support more than one major
release of OTP may need to use conditional compilation of
Erlang source code. Here are few examples where it would be
necessary or desirable:

* To support a new data type or language feature only available
  in the latest major release (real-world examples: maps and the
  stacktrace syntax).

* To avoid warnings for deprecated functions.

* To avoid dialyzer warnings.

Previously, to do conditional compilation, one would have to
use a parse transform or some external tool such as 'autoconf'.

To simplify conditional compilation, introduce the -if and -elif
preprocessor directives, to allow code like this to be written:

-if(?OTP_RELEASE =:= 21).
  %% Code that will only work in OTP 21.
-else.
  %% Fallback code.
-endif.

What kind of expressions should be allowed after an -if?

We certainly don't want to allow anything with a side effect,
such as a '!' or a 'receive'. We also don't want it to be
possible to call erlang:system_info/1, as that could make the
code depedent on features of the run-time system that could
change very easily (such as the number of schedulers).

Requiring the expression to be a guard expression makes most
sense. It is to explain in the documentation and easy for users
to understand. For simplicity of implementation, only a single
guard expression will be supported; that is, the ',' and ';' syntax
for guards is not supported.

To allow some useful conditions to be written, there is a special
built-in function:

defined(Symbol) tests whether the preprocessor symbol is defined,
just like -ifdef. The reason for having this defined/1 is that
the defined test can be combined with other tests, for example:
'defined(SOME_NAME) andalso ?OTP_RELEASE > 21'.