Support for custom HPXMLs

[joseph-robertson]

Pull Request Description

Adds optional hpxml_directory field at the feature level.

Questions:

• if supplied, do we want to throw error if any other input-related fields are provided (e.g., floor_area, number_of_stories, etc.)?

Checklist (Delete lines that don't apply)

• Unit tests have been added or updated
• Documentation has been modified appropriately
• All ci tests pass (green)
• An issue has been created (which will be used for the changelog)
• This branch is up-to-date with develop

[DavidGoldwasser]

@rawadelkontar do you have thoughts about this related to reporting. I know we still need the GeoJSON footprint, and ideally the footprint area matches that. I see number of floors I thought that with floor to floor height would be used to shade adjacent structures (when enabled). I don't see floor to floor or total building height, in my features, but maybe there is default used.

[joseph-robertson]

We need to decide which of these required inputs become optional (or even excluded) if hpxml_directory is supplied. They would become optional because they are parsed from HPXML files in the populated hpxml_directory field.

In theory they all could remain as required, and then be used for error-checking against HPXML files in hpxml_directory. For example, total up all the floor area represented by the HPXML files, and check against floor_area at the feature (building) level. Or sum all the HPXML files and check against number_of_residential_units.

@kflemin @DavidGoldwasser

[kflemin]

looks good! thanks!