(PDB-950) Added validation for regexps in queries

This commit adds a validation for regexps in queries as was proposed in PDB-950
> Hmm, what if we leave that check for HSQLDB only and for PG instead of sending another request just for validation, simply catch org.postgresql.util.PSQLException and generate normal 5xx error? 

What I said in my previous comment was to just make it work for both, and we can figure out with some functional testing and perhaps some more thought whether we need a conditional. You (or us) can change this later, but I'd just raise a patch that tried to do the validation for now for both db's. That way we get it in front of us and we can see how it feels when working. You never know, this might be enough.

> (I don't think that we can return 4xx error in this case, as you already said - it is hard to say whether it was user's invalid regexp or our internal one)

I don't think I said anything about determining the difference between a user regexp or an internal one ... I'm not sure what you mean here, or perhaps I wasn't clear. No, the goal of PDB-950 is to not make it a 500 error and reflect it as a user error status code, ultimately this must be our destination otherwise we're just wasting time and moving the problem around. That is, I'm not sure what the value of any extra validation if all we do is still return a 500 status. We must be able to differentiate from consoles whether the user must take action, or whether its a fault in our system.

Perhaps what you misunderstood is the difference between validating it up front, versus validating it by catching the exception. Validation up front can allow us at some point to point to the user and say "this part of the query broke it" for example they may have done multiple regexp queries and only one failed. On the flip-side if we just catch the exception later on however, we can't express this to a user in the form of their query ... ie. 'something broke' but its up to the user to determine which. Either way, there is a much greater chance that its still a user problem that they need to fix, so a 500 would not be valid here, and a 400 would apply instead.

Half the trick would just be making sure that the exception we catch from the system is analyzed correctly for this particular failure. Strings aren't great, but I believe if we analyze the PSQLException there is probably an error code (getErrorCode) or state (getSQLState) we can match on for this kind of failure instead, that should be far more stable and reliable. Either way, matching this kind of thing can be tricky, so a unit test that actually shakes up the PSQL failure would be needed to ensure this doesn't regress I think.