Add `const` specifiers to various virtual member functions

[program--]

This PR adds const specifiers as applicable to classes associated with DataProvider<...>.

The primary reason for this change is to ensure const-correctness within the DataProvider class hierarchy, as there's no reason not to (at least no reasons that I can think of immediately).

Changes

const qualifies the following:

data_access::DataProvider

+ `get_available_variable_names` + `get_data_start_time` + `get_data_stop_time` + `record_duration` + `get_ts_index_for_time` + `is_property_sum_over_time_step`

realization::Formulation

+ `get_formulation_type` + `get_required_parameters`

realization::Catchment_Formulation

+ `get_output_header_line`

realization::Bmi_Formulation

+ `convert_model_time` + `get_bmi_input_variables` + `get_bmi_model_start_time_forcing_offset_s` + `get_bmi_output_variables` + `get_config_mapped_variable_name` + `get_model_current_time` + `get_model_end_time` + `get_model_type_name` + `is_bmi_input_variable` + `is_bmi_model_time_step_fixed` + `is_bmi_output_variable` + `is_model_initialized`

Checklist

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

[PhilMiller]

I think is_property_sum_over_time_step should also be const

[PhilMiller]

Re noexcept:

• I don't think it's a good idea to start applying that qualifier without really thinking about it project-wide
• In this particular case, I don't think we can actually apply it accurately to all implementations of these DataProvider methods. They may call into BMI routines that might fail for whatever reason. We want that exception to get thrown and potentially handled at whatever level, and not just immediately call terminate when they hit this layer of the call stack.

So, my take is that we should go ahead with adding const, and hold off on noexcept for now.

[program--]

Re noexcept:

...

Yeah I agree. I forgot the extent of the DataProvider hierarchy (thankfully CI reminded me 😄), but I'm happy with only const being added.

[PhilMiller]

This all looks good, but I'm sick enough that I'm not going to press "merge" on anything myself today.