E2E encryption implementation using Bouncycastle FIPS provider and only the FIPS-library provided tools

### Search before asking

- [X] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.

### Motivation

my firm would like to use Pulsar but using Bouncycastle FIPS approved libs in approved mode for E2E encryption.

Currently the `MessageCryptoBc` is the only `MessageCrypto` implementation (non FIPS), and it is explicitly referenced from `ProducerImpl` and `ConsumerImpl` - unless overridden.

I think it would be greate if someone adds an encryption key and a CryptoKeyReader, based on the loaded modules pulsar would use the fips or non-fips implementation. As related job has been done in pulsar to separate out different version (non-fips or fips) of BouncyCastle dependencies, we could expand on it.

### Solution

An idea about the tasks:
1. Create a new MessageCrypto implementation using only bouncycastle FIPS provider and API calls and add it to a new `org.apache.pulsar:pulsar-client-messagecrypto-bcfips` module (`pulsar-client-messagecrypto-bc` already exists).
2. ProducerImpl and ConsumerImpl should check which version (bc or bc-fips) of MessageCrypto can be found on the classpath and that should be used. Decision should be logged. Defaulting back to the origial non-fips solution for backward compatibility if both are on classpath.

### Alternatives

n/a

### Anything else?

Notes:
- ECDSA keys cannot be used to wrap/encrypt keys - in BC's FIPS library only RSA or ELGAMAL cyphers can wrap keys (https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf, chapter 4)
- in MessageCryptoBc data key encryption is using encrypt/decryp mode of cypher, but it should use wrap and unwrap (please confirm)
- SecureRandom should be changed probably in the new MessageCryprto implementation: maybe using "NONCEANDIV" for IV generation (what is done for each message), and another "DEFAULT" type for AES data key generation (DEFAULT may exhaust entropy if used for Nonce and IV generation)

### Are you willing to submit a PR?

- [X] I'm willing to submit a PR!

Start by reading MessageCryptoBc and its references in ProducerImpl and ConsumerImpl, then review the existing pulsar-client-messagecrypto-bc module and the BouncyCastle FIPS constraints described in the issue. The work is done when a separate FIPS message-crypto module uses only approved provider APIs and the producer and consumer select and log the available implementation with the stated fallback behavior.

Written by the indexing model from the issue text.