Wrap ESMF_VMBroadcast() for ease of use

In #1991, @jedwards4b replaced a deprecated call of `shr_mpi_bcast()`:
```fortran
call shr_mpi_bcast(force_send_to_atm , mpicom)
```
with `ESMF_VMBroadcast()`:
```fortran
call ESMF_VMBroadcast(vm, tmp, 1, 0, rc=rc)
```

In the discussion, @billsacks raised [the following concern](https://github.com/ESCOMP/CTSM/pull/1991#pullrequestreview-1397956507):
> I feel like the best way… would be to maintain something like shr_mpi_mod (named the same or different) that wraps the relevant ESMF routine: that way the implementation could be based on ESMF_VMBroadcast but the use from CTSM and elsewhere would be no more complex than is currently the case – and we wouldn't need to make this many changes throughout the CTSM code.
>
> I would tentatively envision an interface similar to the current shr_mpi_bcast but without the mpicom. For broadcasting a scalar logical, you could call something like `shr_[something]_broadcast(force_send_to_atm)` (edit: maybe `shr_comm_broadcast`). In my tentative vision, there would be two optional arguments:
>
> 1. `vm`: Input: If not provided, this is obtained through a call to `ESMF_VMGetCurrent`. (It may not be worth providing this optional argument; the only reason I can see for it is a slight efficiency if you are doing a lot of calls with the same vm, to avoid having to get the vm over and over for each call.)
> 2. `rc`: Output: If provided, then the caller should check this value; if not provided, then the broadcast routine should abort if there is an error. I know that aborting in place doesn't follow the standard of what's done for ESMF return codes, but I feel that adding and maintaining all of the necessary propagation of errors up the call chain could be awkward in some places, so having the convenience of allowing the code to abort in place in the (unlikely) event of an error seems helpful.
>
> If we don't do that, then I have a couple of inline comments that should possibly be addressed for the current implementation.

It was decided that I would go ahead and bring in that PR but start an issue to make sure this idea is not lost.