Fix loading AZFP data

[emma-ozanich]

@emma-ozanich suggestion: Just work on "unpack_ek60.py", but fix load_ek60_raw() function so it succeeds with AZFP (and then define as new function)

Other suggested tasks (@leewujung)

• [ ] Download one .01A file from OOI raw data repository, such as this one
• [ ] Request one corresponding .nc file using OOI M2M or yodapy for verification purpose
• [ ] Identify the code pieces and functions that can be deleted (those are the ones created for the entire mi-instruments package)
• [ ] Try unpacking the .01A file and set up test functions (hence related to #9) to see if the unpacked results are identical to the ones requested from OOI M2M

[leewujung]

The field definitions may be a bit different from this parser but i suspect the structure is similar to this EK60 driver that i based my code from.

[bnwkeys]

• [ ] (major) unpacked AZFP data is not being saved
  • will require debugging script to interrupt before plotting routine and write out data
  • unpacked AZFP data needs to be packed into netCDF format
• [ ] (major) refactor code, get rid of object-oriented paradigm
  • this is literally MacGyvered together from object-oriented code
  • to properly create a standalone utility:
  • break script during file read routines
  • extract necessary config information, metadata, and parsing instructions
  • replicate only parsing routine in a new script and copy in static configs and meta
• [ ] (major) rev-engineer matlab scripts to check for compatibility
  • test current script against other sample data
  • check for flexibility of code to handle all use cases reading all AZFP data
  • make sensor/config agnostic
  • validate against vendor code (matlab)

[leewujung]

The Issues apparently were not imported to the OSOceanAcoustics repo :( @bnwkeys could you create an issue there that capture these? thx!