remove direct YubiHSM support; replace with generic HSM support

[spoonincode]

Direct YubiHSM support was integrated in to keosd by way of integrating libyubihsm in EOSIO 1.7. While this generally works well enough, it is not without problems:

• It brings in a number of dependencies (curl, libusb, pkg-config). Originally I shrugged these off as being super common and thus not onerous to depend on. But, we have indeed seen problems like some sort of curl+pkg-config issue in homebrew at one point. Also, libusb is LGPL which may introduce some problems in the future if we simplify our binary releases. Finally, these days, for the most part I’d like to see a reduction in dependencies; I don’t believe YubiHSM support is worth the baggage of more dependencies when there is a reasonable alternative.
  (I experimented with resolving much of the dependency issue in refactor yubihsm: drop curl & pkgconfig build deps; libusb runtime dep EOSIO/eos#9075, but, while clever, I consider it less desirable than my preference of wholesale removal)
• libyubihsm’s cmake files don’t follow what I’d consider best practices; and if anything they aren’t consistent with the rest of EOSIO’s cmake environment. For example, it uses pkg-config to find OpenSSL instead of cmake’s find_package() as other components in EOSIO do. This can lead to some inconsistencies and makes it impossible to static link OpenSSL, for example. It also is the sole blocker for natively building EOSIO for ARM on macOS.
• There are no unit tests for YubiHSM support. I haven’t personally tested it in over a year; maybe two.

I propose removing YubiHSM support and replacing it with PKCS#11 support. PKCS#11 support will allow using a wide range of HSMs with keosd. YubiHSMs can continue to work via this interface along with other HSMs like Yubikey 5, TPM, Amazon CloudHSM, Nitro Key, ultra low cost generic Javacards and many more (it’s a wide industry standard).

The one downside is that it will no longer be possible to create keys on the HSM via keosd. (PKCS#11 defines two users each with their own password: one to create keys, one to then use the keys; it’s not clear how to map this pattern to keosd) Most likely how this will end up working is that keosd will always log in as the user which can use keys, and a separate tool will ship with EOSIO, let’s call it eosio-p11tool, that can be used to create keys if seeing the PUB_R1_ format is important at creation time. (there would be no requirement to use eosio-p11tool to create keys, it’s just if creating keys with a generic PKCS#11 tool such as pkcs11-tool it wouldn’t be possible to see the PUB_R1_ format of the created key unless running something like eosio-p11tool --list later)

[stephenpdeos]

The team has agreed it is okay not to have a 1-to-1 replace at time of removal targeted for 4.0 release. We'll also get a headstart on comms signifying this deprecation.