Created shared STTP code implementation for GSF and Gemstone library targets

[ritchiecarroll]

This update creates two primary projects: sttp.gsf and sttp.gemstone, where both projects use the same shared code project sttp.core. The goal with this update is to use the "same" STTP code for both GSF and Gemstone to reduce or eliminate code duplication and diversion.

Most code library using references were migrated to global using statements that are defined within the corresponding primary projects. For the most part, this step solves the issue of using the same base code for both GSF and Gemstone, allowing two different assemblies, targeting two different .NET platforms, to be created from the same source code using independent code libraries.

In places where library code was incompatible, a compile time conditional directive is used, e.g.:

#if NET
    using AdoDataConnection database = new(ConfigSettings.Default);
#else
    using AdoDataConnection database = new("systemSettings");
#endif

The highest concentration of these directives is in DataSubsciber - but there are only around 15 of them in the entire project, so they do not distract from code readability, IMO.

Use the Development solution configuration to build this project with code-level access to Gemstone libraries.

Note that using the Development solution configuration requires a project directory structure setup like the following:

project_root/
    gemstone/
        common/
        timeseries/
        ...<other Gemstone projects>.../
    sttp/
        gsfapi/

Root organization repo names are not critical, but relative path locations and referenced repo names, i.e., Gemstone project folder names, are important.

I do not want to merge this PR until Gemstone nightly build is verified to be building NuGet targets and both GSF and Gemstone automated builds have been verified to properly work - may need to adjust build operation to handle dual outputs. Also, want to do a little testing first, such as with EE work, to ensure code is working as expected.

Also, may want both a "dev" solution that includes Gemstone relative project references as well as a normal solution, without these references and without a Development solution target, i.e., a separate solution which only targets NuGet package references that can be used with automatic build.

[ritchiecarroll]

Looks OK