Re: queryId constant squashing does not support prepared statements

> In v17, we are a bit smarter with the numbering, with a normalization
> giving the following, starting at $1:
> select where $5 in ($1, $2, $3) and $6 = $4
>
> So your argument about the $n parameters is kind of true, but I think
> the numbering logic in v17 to start at $1 is a less-confusing result.
> I would imagine that the squashed logic should give the following
> result on HEAD in this case if we want a maximum of consistency with
> the squashing of the IN elements taken into account:
> select where $3 in ($1 /*, ... */) and $4 = $2
>
> Starting the count of the parameters at $4 would be strange.

yeah, I think the correct answer is we need to handle 2 cases.

1. If we don't have a squashed list, then we just do what we do now.

2. If we have 1 or more squashed lists, then we can't guarantee
the $n parameter as was supplied by the user and we simply rename
the $n starting from 1.

therefore, a user supplied query like this:
```
select where $5 in ($1, $2, $3) and $6 = $4 and 1 = 2
```

will be normalized to:
```
select where $1 in ($2 /*...*/) and $3 = $4 and $5 = $6
```

To accomplish this, we will need to track the locations of
external parameters to support the 2nd case, because we need
to re-write the original location of the parameter with
the new value. I played around with this this morning and
it works as I described above. Any concerns with the
behavior described above?

--
Sami