Add support for input slices

[Aflynn50]

This PR adds support for slices in SQLair inputs.

For example, for a named slice type S:

SELECT &P.* FROM p WHERE id IN ($S[:])

Slices of any length can be passed to the query as an argument. All the slice will be included in the query. There are plans to extend this syntax to allow taking slices of slices from within the SQL query itself.

The length of the slice arguments that the user passes are not know when the SQLair statement is prepared. The implementation therefore moves the generation of the SQL from the Prepare phase to the Query phase.

Normally, statements prepared on the database are cached and reused, however, because the SQLair generated SQL of the slice statements depend on the arguments to the query, statements containing slices are not currently cached. They are generated per query and not saved. There are plans cache statements containing slices however it is still a work in progress.

[Aflynn50]

Update on PR state and notes from in person discussion with @letFunny and @niemeyer

Before the meeting on 03/11/23 this PR only allowed slices in IN clauses in the SQL statement. A SQLair IN clause could contain slices, structs (though not with an asterisk) and maps. The syntax for slice inputs was $S.* where S is a slice type. The slices had a maximum length (set at 8). If the user passed a slice with a shorter length then the inputs to the IN clause would be padded out to 8 with NULL values.

This approach had a number of drawbacks:

• There was no way to mix literals and SQLair inputs in the IN clause. (e.g. IN ($S.*, "mystring"))
• There is no obvious way to extend the syntax to access slices of the slice (e.g. S[:10] in regular Go)
• Slices could not be used elsewhere in the query due to the padding with NULL values giving unpredictable results
• The slices had a fixed length

A new approach was proposed in the meeting:

• Slices are written as S[:] in the query. This syntax will put the whole slice in the query. To reference part of the slice the user can write S[:10], S[10:] or S[10:20]
• The SQL generated by SQLair has the exact number of elements in the slice (e.g. if the length of slice is 3 we generate 3 input placeholders in the query for it). This has the disadvantage that we cannot cache the prepared query and reuse it with the current setup since the generate SQL depends on the argument slice length passed to Query. A PR will be brought in the future to address this.
• Slices are not limited to only IN clauses. They can be placed anywhere in the query.

As the PR stands at time of writing, the slices are no longer limited to being in the IN clause, the slices can be any length (though the statement prepared on the database is not cached) and the slice is no longer padded out to a fixed length with NULL values.

The new syntax S[:] is implemented (in a naive way) for inserting a full slice into a query.

Supporting taking slices of the slice within the query is a work in progress and may appear either in this PR or in a follow up PR.

[Aflynn50]

This PR is being put on hold whilst we redesign the pipeline in the expr package. The current abstractions are not suited to the changes needed to add support for slices. This feature is still the priority, but may come in the form of multiple smaller PRs rather than this large one.

The problem with the current pipeline is that the SQL is geenrated at the Prepare stage meaning that it cannot depend on the input arguments. When a slice input is used in a query, the length of the input slice determines the number of argument placeholders in the generated SQL. The pipeline needs to be redesigned to allow for the SQL to depend on the input arguments.