Fix double-free memory management bug

Summary

Removes the attempt to free memory that is already managed by Haskell's internal memory management.

Details

When used as a WASM module with Javascript the compiler occasionally fails with an out-of-bounds memory error. This is because the Javascript client is attempting to free memory that is already managed internally by the compiler.

Specifically, it is the string generated by the compiler that is already managed. In most cases freeing this twice doesn't cause an issue at runtime as the compiler hasn't yet freed it. However, some queries seem to trigger garbage collection and these consistently fail.

The fix is to simply remove the LOC that frees this explicitly in javascript and let the compiler module handle it.

The memory management of query and arguments also needed to be improved. It was attempting to free UTF-8 strings instead of pointers to CStrings. I've no idea why this ever worked.

Verification

This change additionally includes a new benchmarking page, which runs randomly seeded queries at a set rate (currently 500/s). This allows the use of Chrome DevTools to observe memory allocation.

With the code removed, no growth in memory is observed, even over 2-5 minutes. Given that even a small glql query generates GraphQL of 200 bytes or more, one would expect growth of 100KB/s or more if there was a memory leak.

The query and compiler arguments are allocated manually using calloc. Removing memory management for these results in a very small accumulation that is garbage collected by the Chrome V8 runtime every 3s or so:

As such, there is no overall accumulation that would crash the browser and, in reality, the garbage collection would never really create a noticeable problem. It's simply good practice to manage the memory properly and to lay good foundations for the future.

Related to #45 (closed).