❓Should the `options` be hidden in the `metadata`?

[mbercx]

The metadata namespace has inputs such as call_link_label, description, disable_cache, ... These make sense as "metadata", i.e. these do not directly affect the calculation (only perhaps if it is executed, e.g. dry_run, disable_cache), and I think most users (i.e. not plugin developers) don't need very often. However, the options sub-namespace of metadata contains a lot of very important inputs most users need to run calculations, such as scheduler inputs etc.

Having the options here has a few disadvantages:

1. They are more difficult to find when setting the inputs. Users exploring the code might look at options more quickly for setting scheduler inputs than metadata
2. They are not part of the provenance. This used to be a serious problem for reproducibility, which was fixed by switching from non_db to the is_metadata keyword in 65772283028d767430fccb76e3e78bcf2e225bab, and storing the metadata inputs on the attributes of the CalcJob node. However, how many users will know to look there?
3. It adds another level to the inputs hierarchy, making it more challenging to set inputs (correctly).

This is related to https://github.com/aiidateam/aiida-quantumespresso/issues/1122, where I propose to move the options to the top level for e.g. the PwBaseWorkChain (and then pretty much all calculations and BaseRestartWorkChains, for consistency). One thing I hadn't considered there is if we should keep the is_metadata status of the options, i.e. if they should be in a proper input node or not. Have to consider this some more, but wanted to raise the topic.