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

[bartgol]

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.