Change the logic and behaviour surrounding '--api' and 'no-deprecated'

Change the logic and behaviour surrounding '--api' and 'no-deprecated'

At some point in time, there was a 'no-deprecated' configuration
option, which had the effect of hiding all declarations of deprecated
stuff, i.e. make the public API look like they were all removed.

At some point in time, there was a '--api' configuration option, which
had the effect of having the public API look like it did in the version
given as value, on a best effort basis.  In practice, this was used to
get different implementations of BN_zero(), depending on the desired
API compatibility level.

At some later point in time, '--api' was changed to mean the same as
'no-deprecated', but only for the deprecations up to and including the
desired API compatibility level.  BN_zero() has been set to the
pre-1.0.0 implementation ever since, unless 'no-deprecation' has been
given.

This change turns these options back to their original meaning, but
with the slight twist that when combined, i.e. both '--api' and
'no-deprecated' is given, the declarations that are marked deprecated
up to an including the desired API compatibility level are hidden,
simulating that they have been removed.

If no desired API compatibility level has been given, then
configuration sets the current OpenSSL version by default.

Furthermore, the macro OPENSSL_API_LEVEL is now used exclusively to
check what API compatibility level is desired.  For checking in code
if `no-deprecated` has been configured for the desired API
compatibility level, macros for each supported level is generated,
such as OPENSSL_NO_DEPRECATED_1_1_1, corresponding to the use of
DEPRECATEDIN_ macros, such as DEPRECATEDIN_1_1_1().

Just like before, to set an API compatibility level when building an
application, define OPENSSL_API_COMPAT with an appropriate value.  If
it's desirable to hide deprecated functions up to and including that
level, additionally define OPENSSL_NO_DEPRECATED (the value is
ignored).

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10364)