digest: redefine ::Digest constants with OpenSSL::Digest ones

[rhenium]

Request for comments: Is it safe to do this? Would there be any issues?

The digest library (::Digest) needs to either drop the OpenSSL backend or be updated to use the EVP API sooner or later, as the underlying OpenSSL functions are being deprecated. I personally like the former since it's a bad idea to have almost identical code in both digest and openssl. They currently both use OpenSSL for a historical reason: digest was a standard library before openssl joined it in 2003.

---

Replace the C implementations from the digest standard library with
OpenSSL::Digest ones for increased performance. This makes Digest::SHA1
an alias of OpenSSL::Digest::SHA1, for instance.

At the time of writing the digest library uses OpenSSL too, if it is
detected on compile-time. However, I'm proposing a patch to remove that
code path[1]. The digest library currently uses the legacy low-level API
of OpenSSL, whose use has been discouraged for years for multiple
reasons. While it could also be rewritten to use the newer EVP API, that
requires a breaking change in the Digest framework interface. Also, it's
not desirable to have two identical code (Digest and OpenSSL::Digest) as
part of the standard library.

OpenSSL::Digest inherits from Digest::Class and also implements all
methods provided by Digest::Base. Therefore, it should be fully
compatible from the perspective of features. Note that, however, this is
potentially a breaking change if user code extends Digest::Base for some
reason.

class Digest::Class
  include Digest::Instance
end

class Digest::Base < Digest::Class; end
class Digest::SHA1 < Digest::Base; end
class Digest::SHA256 < Digest::Base; end
...

class OpenSSL::Digest < Digest::Class; end

[1] ruby/ruby#3149

[rhenium]

I think this is a bad idea.