Make sorting of files in measure.xml consistent

[asparke2]

Issue overview

When you run openstudio.exe measure --update ./ on a measure to update the measure.xml file, sometimes the order of the files in the <files> element changes. Not sure if this is a result of running on Windows vs. Mac, but it's annoying when reviewing diffs to make sure that only the expected resource files in the measure changed. See the image below, which shows a diff. The checksums for some of the files changed, but for some reason the files order in the xml also changed, making the diff hard to review.

Current Behavior

When you run openstudio.exe measure --update ./ on a measure to update the measure.xml file, sometimes the order of the files in the <files> element changes. Don't know if this is a cross-platform issue, related to how the files are located and sorted, or what.

Expected Behavior

No matter which platform you run the command on, or how many times you run it, the order of the files listed in the <files> element should change. If the contents of those files did change, the diff in the file should just show changes on the <checksum> lines for those files.

Steps to Reproduce

1. Get a measure with resource files
2. Change something in one of the resource files or in the README.md or the README.md.erb or the test
3. Run openstudio measure --update ./ on all platforms. Review a diff of the measure.xml file.

Environment

Some additional details about your environment for this issue (if relevant):

• Platform: Windows 10
• Version of OpenStudio: OpenStudio 3.4.0

Context

The current behavior makes diffs of the measure.xml files for ComStock difficult to review.

[jmarrec]

Has anyone noticed whether it's actually cross-platform issue? Or has someone seen this happening using the same SDK version?

It's also possible (I would say likely) that it's an OS SDK version issue... we've made a few changes over time as to how we scan for files, and we also updated boost (and it's filesystem library) a few times, so it's possible the change comes from here (and in which case there's nothing to we can do about it...).
A likely culprit at 3.3.0 was this PR: #4417

[asparke2]

I don't know if it's definitely cross platform or an SDK version change, but checking the SDK version should be straightforward.