Switch secrets management to cryptic.

[maleadt]

With the help of @staticfloat I tried switching the JuliaGPU secrets management solution to cryptic-buildkite-plugin. Example use case can be found in JuliaGPU/CUDA.jl#1687.

Although I got it mostly to work, there's a couple of issues that prevent me from using it. The biggest problem is that cryptic is designed to deal with much more complex scenarios, where there needs to be a chain of trust enforced by cryptography, and where secrets need to be (partially) available in as many cases as possible. For this purpose, pipelines can be partially trusted, need to be signed when changed, can (and should) include code that uses secrets in the hashing.

Meanwhile, most JuliaGPU CI users have a much simpler problem to solve: make sure CODECOV_TOKEN/DOCUMENTER_KEY is available for builds on master, and don't have them leak on PRs. With cryptic, that involves provisioning every repository with a repo key, putting almost every job in a secure pipeline (since most jobs submit coverage and thus use CODECOV_TOKEN), and including all of doc/ in the tree hashing (since you could otherwise leak the documenter key from a doctest). That doesn't scale.

Meanwhile, our current system is much simpler: using a single keypair, and only decrypting secrets on the master branch. If we want to move forwards with using cryptic, it probably needs a mode where things are radically simplified.

[DilumAluthge]

I think that, for the Julia ecosystem, we need two different options:

1. cryptic, with the chain of trust.
2. A simpler plugin that makes secrets available iff the build is not a PR build from a fork (i.e. what GitHub Actions does).

I don't think those two options need to be the same Buildkite plugin - I think we can just keep them as two separate Buildkite plugins. So option 1 will continue to be the cryptic-buildkite-plugin, and then option 2 will be a separate repo.