Compile SQLite with nostdlib.

[ncruces]

This seems good enough to go (needs rebuilding the Wasm files).

All that's left to decide is if this is how I want to ship math functions, or if I'll get them from something like https://www.netlib.org/fdlibm/.

For math, this is somewhat slower, but one less dependency.
For everything else, this is a wash, but one less dependency.

[ncruces]

This gives a rough idea of how much slower math functions get:

$ ~/go/bin/benchstat before after 
goos: linux
goarch: amd64
pkg: github.com/ncruces/go-sqlite3/ext/stats
              │    before    │                after                 │
              │    sec/op    │    sec/op     vs base                │
_average-12     126.2n ± 16%   115.0n ± 12%        ~ (p=0.059 n=20)
_variance-12    282.1n ±  7%   284.0n ±  7%        ~ (p=0.779 n=20)
_math/sqrt-12   159.0n ±  4%   158.7n ±  7%        ~ (p=0.952 n=20)
_math/tan-12    196.6n ±  7%   231.5n ±  9%  +17.75% (p=0.000 n=20)
_math/cot-12    393.6n ±  4%   403.1n ±  7%        ~ (p=0.211 n=20)
_math/cbrt-12   401.9n ±  5%   391.0n ±  8%        ~ (p=0.495 n=20)
geomean         236.8n         239.6n         +1.19%

The answer is 20%; sqrt didn't change because it's still an intrinsic.

If instead we implemented math functions in a Go extension, they'd be about twice slower (like cot vs. tan).

The alternative is to come up with an API to do "math functions" that doesn't involve multiple calls to get the type of values, and to return the result. Something similar might help the statistics aggregates, though their API is even more complex.

All in all, 20% slower SQL trigonometry doesn't seem too high a price to pay to get rid of a dependency. I am much more willing to believe that wasm32 as a clang target is a long term thing than the current state of wasi-libc.