Add .oh5 reader for EDAX/OIM EBSD files

[smason747]

Description of the change

Progress of the PR

• Docstrings for all functions
• Unit tests with pytest for all lines
• Clean code style by running black via pre-commit

Minimal example of the bug fix or new feature

>>> from orix import io
>>> xmap = io.load('example_file.oh5')

For reviewers

• The PR title is short, concise, and will make sense 1 year later.
• New functions are imported in corresponding __init__.py.
• New features, API changes, and deprecations are mentioned in the unreleased
  section in CHANGELOG.rst.
• Contributor(s) are listed correctly in __credits__ in orix/__init__.py and in
  .zenodo.json.

[smason747]

pre-commit.ci autofix

[hakonanes]

Hi @smason747, thanks for contributing this reader! Had a quick look, it looks promising.

Do you have some datasets to test with? I don't have any locally. I'd appreciate it if you can share some with me. Online, the only ones I can find are from @vtvivian on Zenodo (https://zenodo.org/records/18557610).

Our IO test strategy so far has been:

1. During development, ensure we can read as many files as we can get our hands on
2. Create a test fixture that reproduces a file, ideally with every edge case found in the real files
3. Test the reader using the test fixture

We also need to explicitly add the reader to the list of plugins so that it is registered by orix.io.load():

orix/orix/io/plugins/__init__.py

Line 41 in 28a0e6e

plugin_list: list[ModuleType] = [

[hakonanes]

@smason747, I would support you if you want to use a more permissive license than GPL for your reader file, specifically, like an MIT or BSD license.

We would need to restructure the reader a bit, so that we don't need to directly import from the crystal map or quaternion modules. But there is no technical blocker. I can handle this.

Note that we've discussed this in the past (#389), and there is no consencus between orix maintainers. I think adoption of orix would increase, which should give more contributors. Adding a more permissive license to new files is the place to start.

[smason747]

I am in favor of using a more permissive license. I do not have a preference between MIT or BSD, but for the sake of making a decision would suggest using BSD-3 for this oh5 reader, as this is the license that was discussed in #389.

[hakonanes]

OK, then I'll make an attempt to introduce a BSD-3 license for the files in this reader and add a note to the README.