Implement bracketed unit parsing in forcing CSV headers

[program--]

Resolves #510 by implementing unit parsing within brackets or parentheses appended to column names in forcing CSV headers.

Additions

• Adds direct implementation in CsvPerFeatureForcingProvider::read_csv.
• Adds unit tests to check for header name resolution (i.e. removing unit declaration and whitespace), correct unit conversions, and correct parsing with non-well-known columns.
• Adds new test data file from cat-27115 with unit declarations, and new non-well-known column.

Testing

• All existing and new unit tests pass locally on Linux with GCC version 12.2.1.

Todos

• Add documentation for unit declaration syntax.

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

[hellkite500]

Other than testing the case mentioned, the implementation looks reasonable to me.

[hellkite500]

Might be good to add a test for extra characters after the unit brackets, e.g. var (unit) extra, ...

[hellkite500]

My only concern is what happens with extra characters after the closing bracket/paren.

[program--]

are we expecting anything after a unit declaration? My understanding was that unit declarations would be required to be at the end, or would not be parsed at all (see the outer if construct)

[hellkite500]

Not expecting it, but should be prepared...a warning, error, or something... Would not catching that case cause some weird behavior in the units that we don't expect or can't track down easily?

[program--]

Maybe we add a check after the well-known checks to check if units is still empty, and throw a warning then? This would then tell us/the user that the column that threw the warning has no unit mapping (i.e. like how UnitsHelper::get_converted_value throws a warning when a mapping doesn't exist).

[mattw-nws]

The issue was originally written to treat this case as brackets that do not represent a unit.... in order for the unit to be recognized it would have to be the last thing in the string. We can revisit if we want.

The thought was that there might be (for some reason??) column names with another set of brackets representing something else. In that case, if they were not at the end, then the brackets and their contents would be ignored by the unit parser. If they were at the end, then the workaround could be to add an extra set of different brackets to the end, which would either have valid units or be empty and picked up as an empty units string (didn't cover this case in the issue though, probably).