redpanda,rpk: make redpanda configuration management forward compatible

[twmb]

A bug we had in the release of v22.1.1 was that a new configuration was added to redpanda that corresponded to a new field redpanda.yaml. Unfortunately, we did not add support for reading that new field within rpk, and any manual set of the new field was stripped when using rpk to start redpanda. This was the cause for PR #4603, which was a major cause for v22.1.2.

To avoid this in the future, we should add something that is forward compatible (or change how this is done entirely). Potential options:

1. Define test within rpk to read and then write back some file that always has all configuration options, and expect this same file to be used in core tests.
2. Remove all redpanda / pandaproxy / restproxy configuration reading & validating from rpk, and treat these sections as opaque blobs. rpk can forward the config to a redpanda binary, invoking redpanda to validate the configuration and return what is valid or invalid. rpk can either error (based on a redpanda error response), or blindly yaml-marshal the config to disk.

I prefer option (2) because it removes any redpanda configuration management from rpk. All rpk will ever need to understand is its own configuration. This is also similar to something I've done in the past: rather than have one system manage everything's configuration, that one system defined an API that other systems implemented to validate configs. Then each other system could manage validating its own config and returning erroring responses.

JIRA Link: CORE-922

[twmb]

FWIW because I think that we should do option 1 even if we want option 2, since option 2 will take some time and requires work within redpanda and a whole new configuration flow.