Having to shim CONFIG object

Jasmine tests don't pick up CONFIG object from base.html, so I have to create a CONFIG object before running TimeRange tests since those tests depend on it. This is the drawback of moving the static variable out of the TimeRange object and putting it at the highest level of the app
TimeRanges are simple, generic ideas. They don't need our app's year-specific requirements built in. It's probably better to put the clamp-to-1993 logic in TimeSeries.js in:
nar.fullReport.DataAvailabilityTimeRange
and/or
nar.fullReport.MostRecentWaterYearTimeRange
That will remove the weird 1993 requirements from the otherwise generic TimeRange tests. Removing this year-dependence stuff from the TimeRange object will also make it easier to implement a future ticket which involves us killing some of the TimeRange functionality and instead delegating to sugar's Range methods.