So right now this won't allow pip installs of packages that need the headers.

To achieve that, we need to, roughly, do this:

1. apt-get install libsqlite3-dev in the Python formula (see https://github.com/heroku/heroku-buildpack-php/blob/343fa959d4c195beb7febe1996340624baf713b9/support/build/php#L59-L71 for a generic way of doing this)
2. ensure realpath is also apt-get installed on cedar-14 in the Python formula (see previous point's link for the pattern)
3. mkdir -p ${OUT_PREFIX}/include ${OUT_PREFIX}/lib/x86_64-linux-gnu
4. cp /usr/include/sqlite3*.h ${OUT_PREFIX}/include
5. ln -fs $(realpath /usr/lib/x86_64-linux-gnu/libsqlite3.so) ${OUT_PREFIX}/lib/x86_64-linux-gnu/libsqlite3.so

This will ensure that the libsqlite3 headers, as well as a symlink for the generic .so library (which gets resolved when compiled against) are included in the built Python tarball

Then, in bin/compile, just before pip install, we need to point the compiler infrastructure at those additional locations:

1. export CFLAGS="-I/app/.heroku/python/include ${CFLAGS:-}"
2. export LDFLAGS="-L/app/.heroku/lib/x86_64-linux-gnu ${LDFLAGS:-}"

This should then allow building e.g. a pysqlite dependency in requirements.txt.

Capturing for future reference:

The reason for the shift in approach is that the apt-buildpack won't load headers properly given the package is still on the platform and ONLY the sqlite headers are not, and thus would not allow users of pysqlite or other utilities to use sqlite on runtime. We're opting to preserve this functionality instead, with added complexity as the tradeoff 🎉

Also important: the c and ld flags will not be updated in this pr, but a future one when this functionality is flipped on. That's a potentially breaking change, so slicing this up there unblocks the rest of this work without causing breakage.