Remove a TODO(3.0) from EVP_PKEY_derive_set_peer()

Remove a TODO(3.0) from EVP_PKEY_derive_set_peer()

The TODO described a case where a legacy derive operation is called, but
the peer key is provider based. In practice this will almost never be a
problem. We should never end up in our own legacy EVP_PKEY_METHOD
implementations if no ENGINE has been configured. If an ENGINE has been
configured then we we will be using a third party EVP_PKEY_METHOD
implementation and public APIs will be used to obtain the key data from the
peer key so there will be no "reaching inside" the pkey.

There is a theoretical case where a third party ENGINE wraps our own
internal EVP_PKEY_METHODs using EVP_PKEY_meth_find() or
EVP_PKEY_meth_get0(). For these cases we just ensure all our
EVP_PKEY_METHODs never reach "inside" the implementation of a peer key. We
can never assume that it is a legacy key.

Fixes #14399

Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14555)