Unicode long-term solution investigation

As suggested in HDF5 issue #5037, a long-term solution to this issue would be to provide ”native” Windows file APIs in HDF5 that accept a wchar t parameter. To make this easier for HDF5 users, a solution might involve converting H5Fcreate(), H5Fopen(), etc., to macros that utilize C11 generics to map to the correct function. For example,
```
#define H5Fcreate(filename, flags, fcpl_id, fapl_id) \
_Generic((filename),\
const char *: H5Fcreate_u8, \
const wchar_t *: H5Fcreate_w, \
default: H5Fcreate_u8, \
)(filename, flags, fcpl_id, fapl_id)"

H5_DLL hid_t H5Fcreate_u8(const char *filename, unsigned flags, hid_t fcpl_id, hid_t fapl_id);
H5_DLL hid_t H5Fcreate_w(const wchar_t *filename, unsigned flags,hid_t fcpl_id, hid_t fapl_id);
```
Note that this solution will likely affect both the VOL and VFD interfaces as well.

- [ ] Investigate the need to set up Windows CI on non-US locales (especially Japan and code pages) to ensure that Windows (and, if applicable, Linux) can always open files (or other HDF5 objects) with non-Latin/ASCII names. Tools like h5dump and h5ls should also work. See #5106