Add stdexcept include to UnitsHelper header

[program--]

This PR resolves #523 by including <stdexcept> in UnitsHelper.hpp. In libstdc++ version 13.1.0, the <mutex> header removed an include to <system_error>, which also removed includes to <stdexcept> and <string>. This caused std::string and std::runtime_error to raise errors on compilation of target core_mediator.

Additions

• Adds <stdexcept> to include/core/mediator/UnitsHelper.hpp.

Testing

• core_mediator compiles successfully and all unit tests pass locally using libstdc++ and libc++ with GCC version 13.1.0, clang 15.0.7, and icx 2023.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Target Environment support

• Linux

[mattw-nws]

This looks good... can you make sure you're rebased on latest master? From the test results it looks like you're missing a5d1102.

[mattw-nws]

This looks good... can you make sure you're rebased on latest master? From the test results it looks like you're missing a5d1102.

Strike that... that's not it... rather it looks like ce0ce46 broke this test... that's odd... @hellkite500 can you double-check that?

[hellkite500]

Looking at error that has cropped up and doing a little digging, this seems to be an upstream bug/issue in the backend arrow library

apache/arrow#15054

[mattw-nws]

Looking at error that has cropped up and doing a little digging, this seems to be an upstream bug/issue in the backend arrow library

apache/arrow#15054

So, the segfault, yes... I hadn't noticed that, actually, but that's definitely odd and likely the above issue.

However... the preceeding message is indicative of it not finding the gpkg file, which I think worked until ce0ce46 ... I'm pretty sure the workflow runs the test at the repo root and not in cmake_build/test, which would make it not find the gpkg at a ../../ location. IOW, the test would still fail without the segfault.

_does_file_exist()]: ERROR: geo_file_path parameter entry ../../test/data/routing/gauge_01073000.gpkg does not exist!!

Hopefully if it finds the file and doesn't exit on that path (probably not closing something in a finally block, which triggers the pyarrow crash), the test will succeed.

[mattw-nws]

Okay, you should be able to rebase on master now and we can get this merged.