Consider dropping hand-written cipher modes

[scott-xu]

We could consider dropping hand-written cipher modes in the library.

1. CbcCipherMode will not be used anymore once PR Use System.Security.Cryptography for TripleDesCipher #1546 is merged.
2. CfbCipherMode is only used for PKCS1 private key encrypted byDES-EDE3-CFB. Suggest user switching to newer encryption method.
3. OfbCipherMode is not used anywhere inside the library.
4. CtrCipherMode is used for AesCipher. We can create a dedicated class AesCtrCipher, just like AesGcmCipher.

With all above concrete classes removed, we can remove the abstract class CipherMode. We can also remove AesCipherMode enum (renamed as BlockCipherMode in PR #1546) and use BCL's CipherMode enum.

Then AesCipher.BlockImpl can be removed, AesCipher.CtrImpl can be removed (moved to a dedicated class per above suggestion).
AesCipher.BclImpl can be removed so that AesCipher can have a pure BCL implementation (without nested Impl classes)

So does the TripleDesCipher.

[scott-xu]

Ideally, there's only below ciphers in Ciphers folder

• AesCipher
• AesCtrCipher
• AesGcmCipher
• ChaCha20Poly1305Cipher
• TripleDesCipher

[scott-xu]

Once dotnet/runtime#89718 is implemented, we don't need BouncyCastle for AesGcmCipher

[Rob-Hague]

I'd be fine with dropping the CipherMode classes now. BlockCipher could also be removed, but BlockCipher.BlockSize should stay (I've seen it used in the wild). It could be moved down to Cipher as public virtual int BlockSize => MinimumSize

I would prefer not to change the public API of AesCipher/AesCipherMode as in #1564 - I still don't think it is worth it

[scott-xu]

I would prefer not to change the public API of AesCipher/AesCipherMode as in #1564 - I still don't think it is worth it

AesCipherMode is code smell or even wrong concept. Cipher mode is not limited to AES only. I know it is public API but we changed public API before. I think it should be fine if we write down the change in release notes.