Handle malformed regex comparisons during parsing (fixes #3301)

[rnubel]

Previously, if your query used a regex operator but didn't follow it with a regex, parseRegex would return an empty RegexLiteral, and the expression parser would put that into the right-hand side of the expression. This caused a nil-pointer panic when the query was later executed. This change adds a check at the parsing level and returns an error message if a regex operator (e.g. =~) is not followed by an actual regex.

Before, doing the following would cause a panic and kill the server:

> SELECT * FROM cpu WHERE value = 0 AND region =~ 'adf' LIMIT 2;
ERR: Get http://localhost:8086/query?db=mydb&q=SELECT+%2A+FROM+cpu+WHERE+value+%3D+0+AND+region+%3D~+%27adf%27+LIMIT+2%3B: EOF

After, we gracefully handle the problem during the parsing stage:

> SELECT * FROM cpu WHERE value = 0 AND region =~ 'adf' LIMIT 2;
ERR: error parsing query: found adf, expected regex at line 1, char 48

• CHANGELOG.md updated
• Rebased/mergable
• Tests pass
• Sign CLA (if not already signed)

[dgnorton]

+1 after CHANGELOG.md update. Thanks, @rnubel !

[rnubel]

@dgnorton: Changelog update added. I think this is all set.

[otoolep]

Rebased here: #3365