Init code design

[JoyMonteiro]

A PR #88 is currently open to change the initialisation to be more predictable, allowing us to run all tests and be able to use NetCDFMonitor stably.

However, the design proposed there is not flexible enough to handle wildcards sensibly, and does not use
information that might be present in component properties to infer dimensions of wildcards.

It is also unclear whether it is required to maintain additional information about "domain" for all variables. Maybe it becomes redundant once we use component properties to infer array shapes.

In the case where there are no components which can provide full information about quantity shapes (when all components in the model use ['*', 'mid_levels'] for example, and the user asks for a state with more than one column), then we need fallback logic to infer shapes. I think the above PR provides this fallback logic, and not much else.

[mcgibbon]

Using the init module data as a check against what the module has would be fine. An exception should be raised if the domains are not the same, based on the dictionary code I suggested. Otherwise it sounds good.

[JoyMonteiro]

just to keep things in this issue, one option would be to us map like

     domain = {
          sorted(['*', 'mid_levels']): 'atmosphere',
          sorted(['*']): 'atmosphere_horizontal',
          'sorted(['latitude', 'longitude', 'mid_levels']): 'atmosphere',
          ...
    }[sorted(list(properties['dims']))]

if we end up retaining the domain logic.