Native crate support

[brainstorm]

Fixes issue #53, where an old LLVM/clang version was preventing rust-htslib crate from compiling inside the docker container.

Might affect other bindgen crates in the future so it is worth having llvm-config et al present on $PATH and reasonably up to date, imho.

Perhaps that clang version should be updated accordingly upstream on lambci container itself as well?

[brainstorm]

@softprops, after reading this, I wonder if we shall add this to the Dockerfile:

rustup target add x86_64-unknown-linux-musl

And then on /usr/local/bin/build.sh pass that same --target accordingly?

[softprops]

sorry for the delay. I'll try to take a closer look into this with in the coming week.

[brainstorm]

Yay, thanks @softprops! Looking forward to have this merged in :)

[brainstorm]

👋

[softprops]

Sorry for the delay on this. There's actually a proposal that might help for custom dependency needs #6

[brainstorm]

Oh yeah, that one looks neat! OTOH, my PR is really just including clang in the mix, that's a pretty common base requirement I reckon? :-S

[brainstorm]

Noticed the alinux2 docker container switch... perhaps clang is installed by default in Amazon Linux 2?

[brainstorm]

I understand the point made in #53 (divergence from upstream lambda environment/image)... OTOH, a quite rust-official docker container that cannot compile *-sys (C bindgen/native) crates can be a bit disappointing DX.

That being said, let me refresh this branch a bit, there might be a more acceptable workaround than pulling in more deps than strictly necessary. If that works I can close this PR with some peace of mind about this ;)

[brainstorm]

Coincidentally that native rust crate requires docker to build (because cross and MUSL), so the level of inception would get a bit too ridiculous when combined with this builder XD

And now I understand what you mean, this is only meant to be a runtime environment, not a build-time env, closing.