Reduce allocations and resolution dependence in how we get surface values from a center field

[kmdeck]

Purpose

Reduce allocations and remove duplicate code

Description

The soil model requires, when setting boundary conditions, the values of the state and certain derived properties (temperature, specific humidity, etc) at the surface.

1. We currently use top_center_to_surface https://github.com/CliMA/ClimaLand.jl/blob/f36042f1e369ea8b15998f56500ecf0f6e9afb01/src/shared_utilities/Domains.jl#L660 which takes the top center value as the surface value, and creates a field on the surface space. This is allocating, and resolution dependent since the value at the top center depends on resolution.

2. We also have https://github.com/CliMA/ClimaLand.jl/blob/f36042f1e369ea8b15998f56500ecf0f6e9afb01/src/standalone/Soil/boundary_conditions.jl#L27 and https://github.com/CliMA/ClimaLand.jl/blob/f36042f1e369ea8b15998f56500ecf0f6e9afb01/src/standalone/Soil/boundary_conditions.jl#L48.

The first method, as far as I can tell, allocates and does what #1 does, but in a cleaner way. The second method is for when we have a scalar (not depth dependent) argument and so we dont need to interpolate.

3. In a recent PR, we introduced linear_interpolation_to_surface!(sfc_field, center_field, z) which allocates when we create the \Delta z field, but does not allocate the surface field otherwise (but instead modifies the values at a preallocated spot). The benefit to this is that it should be less resolution dependent.

Desired solution

1. A single function for extrapolating from the center field values to the surface (we could support both nearest neighbor and linear extrapolation, but Im not sure we need to, as the first is resolution dependent and the latter is less so).
2. We still need to support this handling scalar input
3. All methods non-allocating (this will require adding scratch space) to p. This may require adding \Delta z fields and z to p as well.

Impacts

Since we use this functionality (center to surface extrapolation) a lot when computing BC, especially the "atmos driven ones" this might tie into performance work @Sbozzolo is doing on turbulent_fluxes. These same functions also will show up in the jacobian boundary contribution terms that @juliasloan25 is working on

We may also need to think about where scratch space is stored. is p.soil.sfc_scratch1, p.soil.sfc_scratch2 reasonable? or should we do p.soil.scratch.sfc1? idk. will think more and we can discuss