Right now, we're returning all the results of a given repository's
advisories, which can be extremely large if targeting a monorepo, or
just a repo with a lot of dependencies.

To prevent potentially retrieving and then sending hundreds or thousands
of results to the caller, we can instead set up pagination.

This uses offset-based pagination, but with an encoded cursor, mentioned
in [0] and seen across other APIs. We use offset-based pagination as we
don't have a stable identifier for a given row, and so it's easier to
think of it in terms of an offset.

To do so, we need to change the structure of our GraphQL response, which
allows us to surface pagination information.

We can also add an explicit `pageSize` limit in our schema, so it's
clearer to the user what the default behavior is.

However, this is a breaking change as we're changing the structure of
the GraphQL response, which needs to be flagged appropriately with a
`compatible_since` bump.

This requires that we use a named variable for sqlc for `limit` and
`offset`, otherwise we get errors such as:

    missing argument with index ...

Due to the rest of the query having numbered indexes generated by sqlc.

Closes #564.

[0]: https://betterprogramming.pub/understanding-the-offset-and-cursor-pagination-8ddc54d10d98