Refactor Response Parser

[sarahzinger]

While working on adding backend support for traces as part of #287 I noticed that our response parser could use some refactoring improvements. To make the prs easier to read I've broken them up.

Changes:

• rename newTimeSeriesQuery to newQueryRequest. It seems a bit confusing to describe all the work that happens in there as timeSeries queries (although I do think they often---always?-- have a time field attached).
• similarly rename getTimeSeries to parseQuery I think this more accurately describes what's happening. The request has already been made, the responses just need to be parsed and again I think describing all of the types we support as timeseries feels a bit misleading maybe?
• Pass Datasource Settings in to newQueryRequest, luceneHandler, and ultimately to the requestParser. This will eventually be necessary when adding traces to the request parser because we need to use the datasourceUID and datasource Name to add to the field for TraceId, so that all traceIds are clickable and open an individual trace view. I could have possibly instead accessed this off of client the way we do with configurable fields, but it felt a bit strange to me to add a getter in client to access the datasource, when client's main responsibility is to communicate with open search.
• Pass Configurable Fields to the responseparser when we make it, rather than to the function that parses responses. It felt a bit confusing to me to have multiple places where we pick up inputs.
• Move debugInfo within the if conditional's scipe where it's used inside of parseQuery.
• Add some comments (I was adding them mostly for me as I walked through the code, and I'm note entirely sure they are still valuable but they might be?)

[kevinwcyu]

this line can be removed following the two code suggestions below.

[sarahzinger]

great catch thank you!