Unify specs

Most of them were in the wrong group anyway, by its name;
just use one group.
specs: collect data, dedup code

As a bonus now that the code is deduplicated so it's easy,
test both the for_parameter=true and (default) for_parameter=false
cases.

The test labelled with @teeparham's name turns out to
be essentially the same as what we call "should support
double quotes in strings".  Say it just once, and prefer the
description of what it does to who originally contributed it.
spec: allow choice of test DB

Also comment out the CREATE EXTENSION; it gives me a syntax
error (on 9.1), and in any case it only has to be done once
and is probably not nice to do implicitly anyway.
spec: include more examples in PostgreSQL test
Differentiate parsing own output and PostgreSQL's

When .load is used for parsing data received from PostgreSQL,
it will be given the actual hstore string, not a SQL string constant
describing it.  So don't try to strip off the encoding we
would have performed to produce a SQL string constant.

In the previous version, this could have corrupted data if
a key began with a double dollar sign and PostgreSQL chose
to return the field without enclosing the key in double quotes.
Nothing in the documentation guarantees that PostgreSQL will
use double quotes when optional, though fortunately it empirically
seems to do so in the version I have handy to test with (9.1).

For tests which parse our own output instead of PostgreSQL's,
use for_parameter=true when producing that output.
Add failing test case for injection with dollar signs

As a comment suggests, we can produce the wrong result in some
cases, specifically when the input contains a double dollar sign.

As this test demonstrates, the bug can be turned into an injection
if a user can influence one of the values in the input and is clever.
NB the failure is demonstrated only in the live PostgreSQL test;
it's when PostgreSQL parses the query that things really go wrong.

Fix in next commit.
Escape correctly in the face of dollar signs (and anything else)

As a comment suggested and the 'lol=>lol' test from the previous
commit shows, the previous version would produce the wrong result in
some cases, specifically when the input contained a double dollar sign
-- and this could be turned into an injection by a clever attacker.

It'd be tricky to get this exactly right with dollar-quoting -- from
the docs, it seems to be a mechanism aimed mainly at handwritten SQL
code, which perhaps explains that.  Fortunately another string constant
syntax can be used reliably in PostgreSQL; see code and comment.