Remove BC fill routines other than for State_Type

[maximumcats]

PR summary

This PR removes all boundary fill interfaces other than hypfill and denfill (gravity, rotation, reactions, radiation). The existence of these routines creates substantial maintenance overhead relative to the value they add, since none of the problems actually use them to update the boundaries. As an example of the problem this complexity adds, not all of the routines were addressing inflow boundaries consistently (in particular, some override an inflow boundary to do first-order extrapolation so that there's meaningful data, and some don't, leading to garbage data for e.g. the reactions). The only one of these that a user would be likely to touch was the radiation fill, but we have no problem setups demonstrating this (they all use radiation.lo_bc and radiation.hi_bc instead), and it's also hard to see how a user could have effectively used the radiation fill for a multigroup problem, since you don't come in with information about which group you're in.

PR checklist

• test suite needs to be run on this PR
• this PR will change answers in the test suite
• all functions have docstrings as per the coding conventions
• the CHANGES file has been updated
• if appropriate, this change is described in the docs

[zingale]

for the grav?fill routines, shouldn't it be the case that if we are reflecting, then the normal component of the gravitational acceleration should reflect too? I don't know if we are capturing that.

[maximumcats]

Yes, you are right, and yes we are already capturing that. In development we have:

  set_x_vel_bc(bc,phys_bc);
  desc_lst.setComponent(Gravity_Type,0,"grav_x",bc,BndryFunc(ca_gravxfill));
  set_y_vel_bc(bc,phys_bc);
  desc_lst.setComponent(Gravity_Type,1,"grav_y",bc,BndryFunc(ca_gravyfill));
  set_z_vel_bc(bc,phys_bc);
  desc_lst.setComponent(Gravity_Type,2,"grav_z",bc,BndryFunc(ca_gravzfill));

where x_vel_bc et al. set reflect boundary conditions as appropriate. Then amrex_filccn handles the reflection for us. In the new method this still holds.

[zingale]

yes, I see. I agree this is a much cleaner way to handle these other fields.