Fix for multi-value template vars in tag_values queries

[davejhilton]

This PR addresses an issue we've run into while attempting to create templated dashboards.

Here's our basic setup:

We have 3 template values that are essentially a drill-down—where each template var's allowed values depend on the previous template var(s). e.g.,

Datacenter --> Server Role --> Hostname

where the set of relevant tag values for "Server Roles" depends on the selected Datacenter(s), and the set of relevant tag values for "Hostnames" is dependent on both "Datacenter" and "Server Role".

We have the template vars set up as follows:

$dc = tag_values(system_stats,dc)
$role = tag_values(system_stats,role,dc=$dc)
$fqdn = tag_values(system_stats,fqdn,role=$role,dc=$dc)

The problem we run into is that all of the above vars have "Multi-value" enabled... but the parsing of the tag_values params doesn't handle that correctly.

Once expanded we end up with queries like this:

$fqdn = tag_values(system_stats,fqdn,role={websrv,db},dc={dc1,dc2,dc3}

but the current parsing logic in datasource.js just splits on commas, which breaks the multi-valued "filters". So this PR changes the parsing logic to properly understand multi-values, while preserving existing functionality (and adding lenience for leading/trailing whitespace).

By way of an "FYI"—I originally went down the path of defining a grammar for the query syntax, and using Jison to generate a parser. It actually works incredibly well—and is the more correct and robust solution. However, I also recognize that it would constitute a more significant code change, introduce the need to invoke jison again in the future to regenerate the parser any time the grammar were updated, etc. So in the name of being non-invasive, I opted to just adjust the existing regexes in this PR.

But if you're interested in seeing the grammar and how it behaves, see this gist which can be pasted into jison "try it" editor to see it in action. The grammar could also easily be further extended to handle the other query types, such as tag_names() and metrics()—and provides a far more robust and maintainable solution for that, should it be decided that the process/code overhead is an acceptable tradeoff.

I'd potentially be willing to whip up an alternate PR using that solution instead, if preferred -- let me know