For initial runs, allow atm procs to "bootstrap" some initial condition (IC) fields

In EAM, Homme bootstraps some fields, like dp3d and phi, from ps (assuming hydrostatic state). Currently, SCREAM _requires_ all IC fields to be loaded from file (either set to constant via yaml file, or loaded from netcdf file). It would be nice if SCREAM could use files like `cam.i` for ICs. These files contain `ps, U, V, T, q`. In order to use these files, we need to allow some runtime features:

- Allow scorpio to read vars by renaming them. We can allow specification of fields names in the yaml IO file as `Fields: [ ps, T_mid=T, ...]`, which our IO class can interpret as "the FM field T_mid is to be read/written from/to nc file as T".
- Allow atm procs to claim "bootstrapping abilities for certain fields. E.g., Homme could claim to be able to bootstrap "pseudo_density" and "phi_int". The flow would be roughly the following:
1. Each atm proc could register itself as a "FieldInitializer" when the field is set in the process (via `set_[required|computed]_field`).
2. During the call to `initialize_fields()`, the AD would _not_ add those fields to the list of fields that scorpio needs to load from nc file.
3. Upon loading all other fields, the AD `atm_proc->initialize_fields()` for any atm proc that claimed to be an initializer of some field. The atm proc can use any other field at this point, since they have been loaded from file.
4. Option: in case atm proc 1 (AP1) wants to bootsrap field F1, but the bootstrap requires field F2, which is bootstrapped by atm proc 2, we could make the request for being an initializer a bit more complex. Namely, when AP1 registers itself as initializer for F1, it can list all other fields needed for the bootstrapping, like `F1.add_me_as_initializer("F2")`. Then, the AD can make sure that a) there are no circular dependencies, and b) the bootstrapping happens in the correct order.