First attempt was to remove `file_utils` in favor of direct calls
to things like `std::filesystem::exists` and
``std::filesystem::path::get_extension`. However, many places in
openmc use strings to store paths to files and directories which
would require patterns that previously look like
```cpp
if (!file_exists(member_string_var_)) {
...
}
```
where a class stores a string file path at `member_string_var_`
to change to
```cpp
std::filesystem::path p(member_string_var_);
if (!std::filesystem::exists(p)) {
...
}
```
This second pattern would be repeated in a lot of the code base,
so keeping `file_exists(std::string)` means less repeated code.

An alternative is to use `std::filesystem::path` objects to represent
paths to files and directories. This would work pretty easily in at
least two locations:

- `Library::path_`
- `DAGUniverse::filename_`

But the primary source of "strings for paths" is due to various
settings, e.g., `settings::path_input`. I don't believe those can be
converted to `std::filesystem::path` objects because they must be
more portable to C and, by extension, Python.

Closes openmc-dev#3041

Always writes an h5 formatted file to the provided
filepath, even if the extension is not .h5

Always writes an h5 formatted file to the
provided filepath, even if the extension is not .h5

Previous implementation returned the substring up to and including
the final directory separator. This is not consistent with
`std::filesystem::path::parent_path`

This reverts commit b6b9765.

Avoids needing to modify a user-provided file name in
write_source_point and write_mcnp_source_point