Post-evolution rewrite cleanups

[nilsdeppe]

There are a lot of things that will need to be removed or cleaned up once the evolution code changes are complete. I'll use this issue to try and keep track of them all, but I'm sure I'll miss some.

Domain/boundary conditions

A list of things to clean up in domain, domain creators, etc. once boundary conditions are fully supported in the code. Since they're currently treated optionally to avoid breaking existing code there are cleanups and improvements to be done.

• [ ] consider removing the periodic_in options in the domain creators. While we want to support creating a domain without boundary conditions for things like ExportCoordinates or a future ApplyObservers executable, these domains probably shouldn't be periodic either since the executables should just perform pointwise operations.
• [ ] make the boundary condition arguments in the constructor be before the time dependence arguments, and not have the boundary condition arguments default to nullptr
• [ ] enable an ERROR in the Block constructor that is currently commented out
• [ ] remove default value for boundary_conditions in Block and Domain constructors
• [ ] ~remove TestHelpers::domain::BoundaryConditions::MetavariablesWithoutBoundaryConditions since all domain creators will require boundary conditions~ We might want this since being able to construct a domain without boundary conditions is something people want.
• [ ] remove if (boundary_condition_ != nullptr) checks in create_domain functions of domain creators, since they all will require boundary conditions to be specified. Some exceptions might be necessary here for periodic domains.
• [ ] the constructors of the domain creators have a lot of default values. These should probably be removed.
• [x] remove ImposeBoundaryConditions action(s) and associated code
• [x] If we decide to keep is_periodic_in arguments, then AlignedLattice should use Alternative options for IsPeriodicIn and BlocksToExclude instead of handling that as a PARSE_ERROR
• [x] move MarkAsNone out of the detail namespace
• [ ] factor subtracting mesh velocity from fluxes into helper function to be used in VolumeTermsImpl.tpp and BoundaryConditionsImpl.hpp

Core evolution

Some cleanup not directly related to boundary conditions but that will be possible:

• [x] remove all old boundary corrections/numerical fluxes. These will have been completely replaced and are currently only being kept around to allow the new infrastructure to be added without breaking the existing infrastructure
• [x] remove InitializeInterfaces and InitializeMortars action. This also depends on projecting the normal vectors/Jacobians to the boundaries, which is necessary to support weak+Gauss points with metric-identity satisfying Jacobians anyway.
• [x] remove whatever adds the volume fluxes to the DataBox, since these are now temporaries
• [x] remove whatever adds partial derivatives to the DataBox, since these are now temporaries
• [x] remove whatever adds divergence of the fluxes to the DataBox, since these are now temporaries
• [x] remove char_speeds_compute_tag and char_speeds_tag from the system classes. Several will then no longer depend on the equation of state type, and just the thermodynamic dimension
• [x] remove the old boundary communication and related code and actions. ~Some of these might be getting moved to the elliptic directory.~ We'll just wait until the elliptic code no longer needs them, and then delete it all.
• [x] remove only time derivative computation actions. This is currently still used by the self-start actions test, nothing else.
• [ ] The LTS code can be optimized in the case of a static mesh by first integrating on the boundary, and then lifting. If the mesh isn't moving, these operations commute (analytically) since the basis functions, and face and volume det Jacobian are time-independent. I think one can keep the normal magnitude in the integral, and then this would also work for dynamical spacetimes.

[nilsvu]

remove the old boundary communication and related code and actions. Some of these might be getting moved to the elliptic directory.

I'm preparing a PR that makes the elliptic DG operator independent of these, so they can just be deleted.