Omni hro reorg

[aburrell]

Description

Moves the custom OMNI routines to an instrument module, in accordance with newer pysat style. Also fixes (temporary?) bug in the clean routine when dealing with array-like metadata.

This is a draft because this needs more work that I don't have time to do:

• [x] This does not deprecate the old functions, but it probably should.
• [-] Would also be a good branch to tackle #34. handling downstream

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Updated unit tests, using OMNI locally.

Test Configuration

• Operating system: OS X Big Sur
• Version number: Python 3.8
• Any details about your local setup that are relevant: updated use_header branch of pysat.

Checklist:

• [x] Make sure you are merging into the develop (not main) branch
• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [x] Any dependent changes have been merged and published in downstream modules
• [x] Add a note to CHANGELOG.md, summarizing the changes
• [x] Update zenodo.json file for new code contributors

[jklenzing]

Thinking about development priorities, I'd prefer to pull in the deprecations for the v0.0.4 release and push the tests out to v0.1.0.

[jklenzing]

@aburrell, I've taken this about as far as I can for now. I don't feel comfortable writing the unit tests for the other omni functions because I don't know how to check if the current algorithms are correct. I see three possible routes forward: 1) Review and merge now to get this into v0.0.4. #34 can be handled later. 2) Write unit tests to ensure current output does not change. Rely on reviews to determine if functions are producing correct output. 3) Hand the branch over to someone else.

I should add that the way I'm running the deprecation tests, each function is actually run, so it looks like the coverage is increased. If we take option 1, I should probably update that to avoid confusion in the future. Realized I could use an empty instrument and scan for expected KeyError to evaluate more quickly.