Refactor auc:TimeSeries for more concise modeling

[macintoshpie]

As brought up in the 2020 proposal Add Associated Cost to TimeSeries Option 2, we can more concisely model time series data by grouping reading types within a single auc:TimeSeries element.

This issue is a suggestion to revisit this design when creating version 3 of the schema.

For example (taken from the proposal)

<auc:Scenario>
    <auc:TimeSeriesData>
        <auc:TimeSeries>
            <!-- Add this element -->
            <auc:IntervalReading>
                <auc:Total>123</auc:Total>
                <auc:Peak>123</auc:Peak>
                <auc:Cost>1000</auc:Cost>
            </auc:IntervalReading>
            <auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
            <auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
            <auc:IntervalFrequency>Month</auc:IntervalFrequency>
            <auc:ResourceUseID IDref="ResourceUse-Electricity" />
        </auc:TimeSeries>
    </auc:TimeSeriesData>
</auc:Scenario>

[macintoshpie]

@nllong Is this something we still want to add to v3? Things to consider:

• AT import (is their support for v3 required?)
• SEED import (not too heavy of a lift for us)
• Existing schematron which reference meter readings (211, SEED, ...)
• How do other folks model TS data for multiple data types (reading, cost, etc) -- e.g. PM associates all readings to a single interval

[nllong]

We are going to table this until there is a more specific need.

[macintoshpie]

I think Audit Template's method for representing multiple time series data for a resource use could benefit from this change. E.g. here's a row representing meter data in AT which maps well:

We'd have to update the proposal to handle units for each reading type

@markborkum thoughts in the feasibility of this change for audit template?