Partially typecheck APIformatting module

[mfisher87]

Important

To be merged only after merging #593 and then rebasing

Add type annotations and some refactors to the APIformatting module.

[github-actions]

👈 Launch a binder notebook on this branch for commit 79fccf1

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit ca3f553

👈 Launch a binder notebook on this branch for commit 3da94ef

[codecov]

Codecov Report

Attention: Patch coverage is 54.54545% with 10 lines in your changes missing coverage. Please review.

Project coverage is 65.44%. Comparing base (1606dd0) to head (3da94ef).

Files with missing lines	Patch %	Lines
icepyx/core/APIformatting.py	54.54%	5 Missing and 5 partials ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           development     #598      +/-   ##
===============================================
- Coverage        65.66%   65.44%   -0.23%     
===============================================
  Files               38       38              
  Lines             3122     3128       +6     
  Branches           599      601       +2     
===============================================
- Hits              2050     2047       -3     
- Misses             984      990       +6     
- Partials            88       91       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mfisher87]

This logic (is key "time" or "temporal"?) is repeated just below, so I moved the error statement into that conditional.

In general, assertions should not be used in "the code" (use only in the tests) unless you specifically want the assertions to be controllable at runtime. python -O will disable all assertions like -W disables warnings. So when I moved this logic I also changed it to raise a RuntimeError.

[mfisher87]

This property returns static data, from what I can tell, so I simplified it down, and removed _poss_keys attribute.

[mfisher87]

The typechecker doesn't seem to be good at knowing whether a conditional is "exhaustive", so we're making that explicit here. I used "Programmer error!" to indicate this is something a user should never see. We can create a new error class instead if that makes more sense!