fix: remove the pairing feature from fvm_shared (#2009)

The `pairing` feature from the `fvm_shared` crate isn't used. It causes
problems, as it forces the `subtle` dependency to v2.4.1, although the
rest is happy to have v2.5.0.

Here is a detailed dependency graph and issue outline:

`fvm_shared` depends on `bls-signatures`.
In `bls-signatures` we depend on an old version (v0.11) of `hkdf`.
That version depends on `hmac` v0.11, which depends on `crypto-mac` v0.11.
`crypto-mac` v0.11.0 depends on `subtle` v2. That is fine, it would
automatically select v2.5.0.
The problem is that `crypto-mac` v0.11.1 pins `subtle` to exactly v2.4,
therefore v2.5.0 won't be selected.

The obvious thing is to upgrade in`bls-signatures` the version of `hkdf`
to the latest v0.12.
That would make it possible to use `subtle` v2.5.0.
The problem is that such an upgrade is not easily possible.
`hkdf` v0.12 depends on a newer version v0.10 of the `sha2` crate.
Updating that breaks the `bls12_381` crate.
The reason is the current version v0.8.0 of `bls12_381` depends on an old
version v0.9 of the `digest` crate.

The obvious thing is to upgrade in `bls12_381` the version of `digest` to
v0.10.
That would make it possible to get `hkdf` v0.12 built.
But such an upgrade is and open issue at
zkcrypto/bls12_381#102, which mentions that it's
blocked on zkcrypto/bls12_381#90.
That pull request is about updating do the hash-to-curve draft v16, currently
it's using v12.
We use that code path in `bls-signatures`, else we wouldn't enable the
`experimental` feature of `bls12_381`.
So it's even not clear if we'd want such a change to v16.

Author: vmx

Cargo.lock

@@ -50,6 +50,5 @@ crypto = ["libsecp256k1", "blst", "proofs"]
 proofs = ["filecoin-proofs-api"]
 secp256k1 = ["libsecp256k1"]
 blst = ["bls-signatures/blst"]
-pairing = ["bls-signatures/pairing"]
 testing = []
 arb = ["arbitrary", "dep:quickcheck", "num-bigint/quickcheck"]