Refactor how config/secrets are managed so that all operations go through the controller

[alecthomas]

Currently the controller and CLI both operate directly on ftl-project.toml, as there was previously no mechanism for propagating config down to modules. But now that we have ModuleContext we should change this. We'll need to for the production launch to support AWS anyway, but also because it's quite annoying.

This will entail adding new gRPC endpoints for secrets/config. Another consideration is that currently the CLI allows users to select a different provider (eg. 1Password, Keychain, etc.) per secret. To preserve this behaviour the desired provider will need to be passed to the Controller. However, the valid set of providers will vary depending on the target environment, so the Controller may error if an invalid provider is specified. eg. only ASM will be valid in production, so setting --keychain must error.

We want to start separating out "backend traffic" from "admin traffic", so to that end this new endpoint should be part of a new AdminService gRPC service rather than being part of the ControllerService.

[deniseli]

When we pick this up, should we also think about possibly renaming the existing structs in backend/controller/controller.go named CommonConfig and Config? I don't have strong feelings at the moment, but it could get confusing if we have a ton of different data types in there all named variations of "Config". That said, I don't find the cronjob.Config reference confusing since its package name clearly delimits its scope, so possibly this won't be an issue at all.