Migrate away from Mono's ProtectedData implementation

### Checklist

- [X] I have verified this is the correct repository for opening this issue.
- [X] I have verified no other issues exist related to my request.

### Is Your Feature Request Related To A Problem? Please describe.

Currently, on non-Windows platforms, Chocolatey CLI runs on Mono and uses Mono's `ProtectedData` implementation to obfuscate saved passwords and remembered arguments.

If Chocolatey moves to being build on dotnet, Mono will no longer be used, as dotnet will be the underlying runtime. So then any upgraded installations of Chocolatey CLI on non-Windows platforms will have two issues:
1. `ProtectedData` is not available on non-Windows platforms in dotnet, so an alternative would need to be determined.
1. Any obfuscated data on disk would no longer be able to be decrypted, as the Mono implementation would no longer be available.

Due to the second problem, migrating away from the Mono `ProtectedData` implementation soon would be ideal.

### Describe The Solution. Why is it needed?

There are a number of potential solutions I can think of. All of these would be for non-Windows only, as Windows installs would be able to continue to use `ProtectedData` without interuption.
1. Don't do any obfuscation at all, just save things as plain text.
1. Do some obfuscation, e.g. OR-ing data with a known pattern, converting to base64, other simple obfuscation techniques.
1. Encrypt with a static key that is shipped/embedded into Chocolatey CLI
1. Use a generated encryption key, and save the key somewhere (maybe next to the `chocolatey.config` file?).
1. Use platform-specific key management systems (keychain on Mac, a bunch of different potential options on Linux

I don't think that using platform specific key management would be a good idea in terms of the complexity it would entail. I also don't think that having strings as plain text would be ideal either, as then things like a grep search could immediately show source passwords.

Doing some obfuscation, or using a static key embedded into Chocolatey would be better, but this would mean that if the file was copied to another machine, it could still be decrypted (e.g. if someone pastes their `chocolatey.config` into a gist, or backs it individually).

So using a generated encryption key seems like the best option, and it provides a very similar level of protection/obfuscation to the current implementation. Since the Mono machine level keys are generally globally readable from what I understand, anyone with access to the machine or the file system can decrypt `ProtectedData` blobs from that machine. The one disadvantage I can think of is that it means if the Chocolatey install folder is copied to another machine, the values would still be able to be decrypted. But otherwise, this seems like a good option.

And if people don't want source passwords saved in the config file, they can always pass it in at runtime with `--password`

### Additional Context

_No response_

### Related Issues

- Issue #2436
- Issue #2173

The issue names no files, tests, or entry points; start by locating the current Mono ProtectedData usage and reviewing issues #2436 and #2173. Define the replacement and migration behavior for existing non-Windows data first; done means the chosen approach works on dotnet without losing decryptability of upgraded installations.

Written by the indexing model from the issue text.