rpk: make it harder to misuse "rpk config set"

[jcsp]

"rpk config set" is a schema-unaware mechanism for setting values in a YAML file: one can do e.g. a "set foo bar" and you'll get a foo key in your configuration file.

That's a UX issue in several ways:

• User can typo a key name and it still gets written to the config file
• User can supply a malformed value and it still gets written
• (New in 22.1) User can specify a cluster configuration property name, and write it "correctly" to redpanda.yaml, except that that's not where we keep cluster configuration properties any more.

Assuming we still need this schema-unaware command, there are a few things we could do to make it less of a foot-gun:
A) Compile-in a list of "at time of writing" cluster configuration properties, and refuse to set them in redpanda.yaml with a helpful message about "rpk cluster config edit"
B) Or, as above, but instead of compiling it in, have rpk pull the schema at runtime from the admin api. This has the downside that it only works if redpanda is running, and if rpk has the right host/port for talking to the admin API.
C) Use the existing pkg/config/schema.go definition of node configuration properties to validate any "config set redpanda." command. For unknown properties, provide a helpful message that they might be trying to set a cluster configuration property. In the even that they are trying to set a node property that RPK just doesn't know about (unlikely: local config file edits are happening using the same RPK that is shipped with redpanda), they may have to edit redpanda.yaml directly.

I lean toward C.

[twmb]

This should addressed when addressing #4530: if we remove the implicit magic, we can make these failures explicit. However, I err towards (a).