test_zci: make tests easier to interpret.

- Parallel paths for structured_answers to mirror attributes checking.
- Add '-ANY-' keyword to allow things to match on any result.

Verbose output improvements:
- Wrap each query in a subtest
- Use prefixing to quickly indicate the extent of the test

Perhaps the most controversial thing here is the '-ANY-' keyword, but I
think it's a strong improvement over the fall-back `qr/\.*/` since the
intent is exceptionally obvious and the verbose output will confirm what
is happening.
Good news!  Your questions 1 and 2 are highly intertwined, so I get to tell you a story that I think will help your understanding and review.

In _every_ case on _every_ answer, we eventually go through `is_deeply` (L111) and make sure that everything we got was expected and everything expected was gotten.  If there are extra keys in the response, `is_deeply` will note that we got some stuff we weren't expecting and throw its standard fit.  Similarly if any keys are missing.

So, then, why all this extra code in this first section?  Note that it doesn't _actually_ compare every value.  Any values which do not match `-ANY-` or refer to a `Regexp` are completely ignored by this section, in favor of being checked on L111.

So, we know the expected value is one of these special things.  We also know that there is _very little_ chance that a ZCI result _actually_  contains, say, `qr/[0-9]{4}/`.  So, this is supposed to imply something about the form the data in there... but `is_deeply` is going to be very mad if we try to match it byte-by-byte. 

From there on it's pretty straight-forward.  First, do the appropriate check (from our example: `like(qr/[0-9]{4}/,2014, 'Regexp: structured_answer{input}')` and let it pass or fail as appropriate.  The next part is just as important, though. Make sure that those keys contain exactly the same thing on both structures (see L103, for example).  When we finally fall through to `is_deeply` they will _necessarily_ contain the same data byte-for-byte.

[NB. You can see this happening with the currently released version. Changing a particular test back and forth between a quoted string and a regex will result in the test count going up or down as the "extra" regex test is added or removed.  It becomes a bit more clear on this branch where each `test_zci` invocation results in exactly one test, but with (potentially) multiple sub-tests making up the checks on that query.]

In summary, then, we get to do checks on data where we only _kinda_ know what it should look like (our example regex might be matching a year which changes, err, annually), but still get the assurance of making sure our overall structure looks exactly as intended in the end.