fix #754

[jamescheney]

This PR attempts to fix #754 by adding cases that recognize regular expression matching tests in the let-insertion and flattening stages of shredding. Previously these were handled generically and failing because these stages didn't provide any cases to handle variants (which is how regular expressions are represented at runtime in the IR).

This makes simple tests using regexes inside nested queries, like the one in #754 work, but does not make regular expression handling on the database any more complete/safe than it already was.

I've added debug messages to the two new cases in case we should be doing something more with the regex expressions, so that if we run into problems there will be a debugging message that gives more of a clue what the problem is.

[SimonJF]

Seems to be a simple fix, so looks good to me. My only ask would be a test just to make sure it works within a non-top-level query.

[jamescheney]

I added a test for this in jrules.links, is that sufficient?

[SimonJF]

I was more thinking of something like

sig marketers : () -> [(name:String, clients:[Int])]
fun marketers () {
  for (m <-- marketers_names)
    [(name=m.name, clients = for (x <-- mc) where (x.m == m.name && x.name =~ /a/) [x.c])]
}

just to make sure it works within nested queries, if possible. I'm sure it'll be the same and still work, but it's worth checking.

[jamescheney]

OK,done. Will merge when CI passes.