Refactor common code out of *shape classes

[PMeira]

Most of the code from GrowthShape, TempShape, PriceShape, LoadShape, Spectrum and XYcurve can be moved into a new base/aux class. We can keep these 6 as thinner derived classes. This could also generalize some LoadShape extensions and make it better to maintain the API level code.

[PMeira]

The performance issues for LoadShapes mentioned in dss-extensions/OpenDSSDirect.py#98 (comment) also affect most of these other classes. There is a lot of duplicated code, so a separate class to handle most of the common features will be welcome. A new common class simplifies the work for #93 too, since these classes account for 27 references to AssignFile out of 208 hits -- 136 hits are concentrated in ExportResults.pas, ShowResults.pas, Utilities.pas, Circuit.pas, and ExecHelper.pas, while most of the uses in other files are debugging.

The LoadShape class is the most complete/complex. The new class can follow from that:

• A couple of flag variables can indicate what features are supported by each class.
• We need 3 separate vectors/arrays for doubles.
• They can have generic names in the common class (x, y, z), and the individual classes can be thin wrappers that expose than as the final quantities, e.g.
  • LoadShape: x=>Hours, y=>Pmultipliers, z=>Qmultipliers.
  • GrowthShape: v1=>Years, v2=>YearMult, v3=>Multiplier. Here, Years is originally an int32 array, but a float64 array can represent the same values exactly. We can add a constraint to guarantee integer inputs.
  • PriceShape: v1=>Hours, v2=>PriceValue.
  • TempShape: v1=>Hours, v2=>TValues.
  • XYcurve: x=>X, y=>Y -- this one is also the simplest since it doesn't handle time and intervals.
  • Spectrum: x=>puMagArray, y=>AngleArray, z=>HarmArray. There is also MultArray, which is a complex array, but it's derived from the others.
• Some of the common methods for most classes: SaveToDblFile, SaveToSngFile, CalcMeanandStdDev, Get_Mean, Get_StdDev, Set_Mean, Set_StdDev, DoCSVFile, DoSngFile, DoDblFile, Get_Interval.
• We don't need to use generics/templating. Although one of the goals is to improve performance, the hot path is inside the common functions.

Refactoring these may also mean that we could use new features (external memory and Parquet support) as discussed in
dss-extensions/OpenDSSDirect.py#98 for any of these classes. That is, we could use a single datastore format to support all of them.