Move BuildResidentialHPXML measure to option-based arguments

[shorowit]

The BuildResidentialHPXML measure is currently ~500 arguments and growing. That alone makes it difficult to use, but it's particularly challenging because there are many conditionally-required arguments (arguments that are only required based on the value of another argument). This limits its usefulness for some use cases.

This can be improved by largely moving from property-based arguments to option-based arguments. For example, the measure would replace ~10 clothes washer property arguments with a single dropdown of option names. A TSV file (e.g., clothes washer.tsv) will provide the mapping of an option name to its detailed properties.

(There is obviously some engineering judgment needed as to which properties are incorporated into the TSV. For the clothes washer example, Location and Usage Multiplier should probably remain separate arguments since they can apply to any clothes washer product. For HVAC systems, Capacity and Fraction Load Served would likely remain separate arguments too.)

There are several advantages to using option-based arguments:

• It will significantly reduce the number of arguments.
• It will largely remove the need for conditionally-required arguments. (This logic will be incorporated in the way options are described in the TSV.)
• It can help standardize options across different projects (e.g., ResStock, URBANopt, etc.).
• It removes any friction/resistance around introducing more advanced properties since they no longer directly show up in the measure (they are one level lower in a TSV).

If a user wants an additional option that's not offered, they can:

• Add it to their local copy of the TSV (and depending on how they use the measure, they may have to update the measure.xml prior to using the new option), or
• Open a PR or request a new option be formally added to OS-HPXML.