Add flexible/extensible constituent properties functionality

Description

To facilitate the addition of new host-specific constituent properties fields without cluttering the constituent object, a new abstract class should be created that can be extended by the host models.

Solution

Proposed solution includes

1. Creating new abstract class:

type, abstract :: host_constituent_properties_t
contains
    procedure(host_constituent_get_prop) => get_prop()
    procedure(host_constituent_set_prop) => set_prop()
    procedure(host_constituent_create_prop) => create_prop()
    procedure(host_constituent_has_prop) => has_prop()
end type host_constituent_properties_t

2. Adding new object to constituent properties object:

type, public, extends(ccpp_hashable_char_t) :: ccpp_constituent_properties_t
    character(len=:), private, allocatable :: var_std_name
    …
    class(host_constituent_properties_t) :: host_props

The specifics of the implementation of the host properties object are up to the host model. The only hard requirement at this point, beyond agreeing on the abstract interface, is that any added properties should not negatively impact any physics scheme or framework capability that is used by others (i.e. none of the added properties should be needed by other host models that are not using the host-specific physics features).

Note: We will also want to eventually add property standard names to the ESMStandardNames dictionary for potential shared constituent properties to keep things portable.

The issue does not name specific files, tests, or entry points. Start by locating the constituent properties type and the host-model extension points, then inspect existing abstract interfaces in the framework. Done means the extensible host-properties interface is agreed and implemented without affecting physics schemes or framework capabilities used by other host models.