Some archaeology: it was added in upstream's
ee1d9ec019. This seems to come from upstream's
arrangement where an EVP_MD can specify both the signing algorithm and the
message digest. (Most of the usual hash algorithms were tied to RSA.)

The flag is set on EVP_MDs that should use the EVP_PKEY's method table in
EVP_Sign* rather than the one attached to the EVP_MD (there's also
required_pkey_type to filter on EVP_PKEY to prevent a mismatch). Without the
flag, the old codepath is hit where they're tied together.

Interestingly, EVP_md5 does not have the flag, but I suppose this is because no
one would sign ECDSA + MD5. EVP_DigestSign* also postdates this and doesn't use
the legacy mechanism anyway. Upstream also has, e.g., EVP_ecdsa(). Although
those too have since also gained the flag in
bce1af7762.

Let's get rid of these TODOs. We don't have the old codepath. It's unclear if
upstream really does either at this point.

Note: EVP_PKEY_RSA_method in upstream is actually a macro that expands to three
fields, which is why it's so difficult to figure out what's going on with those
structs.

Change-Id: I1aea4d3f79f1eb1755063bb96c1c65276c6e3643
Reviewed-on: https://boringssl-review.googlesource.com/2122
Reviewed-by: Adam Langley <agl@google.com>

Initial fork from f2d678e6e8 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)