Add greater flexibility in temporal specification

[HeatherSavoy-USDA]

Add a new optional input parameter to specify the months a user wants for data, e.g. when a user is only interested in a particular season. Used whenever monthly or daily data is being returned (see #41), and ignored for annual or non-temporal datasets.

Default: 1-12

Formats accepted: comma separated and ranges (inclusive), e.g. 1,3-6,9 for Jan, Mar, Apr, May, Jun, and Sep.

[stuckyb]

I wonder if we might as well implement this for years, too. E.g., someone wants to sample every other year in a range, or every four years, etc.

[stuckyb]

Also for days. E.g., someone wants only the first 100 days of each calendar year, or last 50 and first 50, etc.

[HeatherSavoy-USDA]

I like it!

Years: Would we want to modify/collapse the current date_start and date_end parameters into a date_range so that users could specify sequences and/or multiple ranges, e.g. thinking of VS and 2004-2006,2009,2012,2014-2015? Could get messy for sub-annual dates. And/Or add additional parameters like a year_step.

Days: We could add a julian_range optional parameter that takes sequences and ranges. This and month_range would still be useful if we did date_range or not.

[HeatherSavoy-USDA]

I added a julian_range and month_range optional parameter and modified _parseDates to use them. I did NOT extend these to the granularity matching in #41 since the date logic needs to be moved from fulfillRequestSynchronous to somewhere better suited and I figured that should be done first.

[HeatherSavoy-USDA]

I'm closing this issue because #60 is a more detailed duplicate