channel routing data extraction

[quinnylee]

See issue #28 . This change extracts q_lateral from the NWM's channel routing data, remaps it onto the nextgen hydrofabric (user must provide mapping, see https://alabama.box.com/s/kpcy8jg772bqpusouzt7wx1gfjn00spb for the latest NHD to NextGen HF 2.2 mapping), and outputs it for the purpose of t-route ingestion.

Additions

• Forcing processor now processes q_lateral from channel routing data and maps NHD values onto the NextGen hydrofabric (because q_lateral is additive, we just add all the values from the NHD that correspond a NextGen nexus together
• Added pytests
• Added examples in docs/examples

Testing

1. ran pytests locally
2. ran examples locally

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Testing checklist

Target Environment support

• Linux
• MacOS

[quinnylee]

This latest commit adds a dask requirement, so if this is merged, our instances will have to get rebuilt to include dask. Dask speeds up the runoff addition step significantly by chunking our xarray dataset when it is opened, which allows for chunked addition of columns. This is super important for large-scale data processing.

Speed comparison (for CONUS-wide processing, 3 hours)
with dask + vectorized operations: 1 minute runtime
without dask or vectorized operations: 15+ minutes (I stopped it before it finished)