Vendor hasql

As briefly mentioned in https://github.com/PostgREST/postgrest/pull/4434#discussion_r2471974421, we'd like to move away from hasql as a dependency. The upstream repository has seen a huge number of commits written with (heavy support of) LLMs recently, v1.9.3.1 is the last version before that.

There are a number of reasons why this makes us feel uneasy and why we'd like to move away from it as a consequence. However, this issue is not the place to discuss these reasons - this issue is about how we're going to implement this change, not why.

My current idea is:

• Update our use of hasql to v1.9.3.1. This requires updating our Nixpkgs dependencies and GHC versions, which I have some long-standing PRs open for in #4182 and #4193. Nixpkgs is now ready for these, so I plan to finish them up now and then also proceed with #4797. PR is: #4829
• Vendor hasql at v1.9.3.1 and the other packages from its ecosystem that we're using and integrate them into our repository and tooling. https://github.com/PostgREST/postgrest/pull/5084
• Strip down the vendored hasql and remove everything we don't actually use to keep the code, that we need to maintain going forward, smaller.

In this scenario, I would vendor the hasql code, and not fork it. That means, I would like to integrate this code in the postgrest repo itself. This has several advantages over forking:

• We don't actually intend to provide this fork on hackage for anybody else to use - we certainly don't want to keep stable interfaces and what not. By not exposing this package separately, this will never be a problem.
• We need far less additional infrastructure, but we can use the nix development environment we already have.
• When doing the last step of stripping down the vendored code, we can actually use the PostgREST-specific code coverage to identify things that can be removed. If it's not covered with our test-suite - it's most likely not needed for us.

My idea would be to keep the histories of the upstream repos and merge them into our own git history - very similar to how we merged the docs repo back into the main repo. We can put all these things at src/Hasql reflecting the different Hasql and PostgREST namespaces we'll still have.

I'm not sure how many of the upstream tests we'll need to maintain or how many of them will be redundant, because they are E2E tested via our own test suites anyway.