Hi, @bagder!

First and foremost, thank you so much for such a wonderful tool and library--and for sharing it with the world.

I was building things across platforms, reading your good docs. Along the way, I noticed that some of the Android instructions seemed to have gotten out of date with the switch to LLVM toolchains in newer NDK versions. So, I figured I'd try to leave things even better than I found them, especially since the triggered error messages are different enough from their root causes. Here's my shot at that for your consideration.

Cheers!
Chris

P.S. To explain some of the changes:

• ANDROID_NDK_HOME is the Google-standard variable for pointing into the NDK, so I thought I should change us over to that, since some people will already have it set and know about it from elsewhere.
• The other variables are just the result of changed paths in the NDK with the switch to llvm tools. The old paths are no longer valid, which can cause issues that look like missing SSL libraries.
• I think the LIBS/static linking issue probably predated all this. LMK if you have a cleaner way to express that--I'm certainly no auto tools expert, unfortunately. The error otherwise misleadingly manifests itself as the script thinking libcrypto is missing SSL_connect. And BoringSSL needs libc++, so I included it, thinking it was better to be safe than sorry.
• Finally, the reason for the removal of the API-level 23 sentence, is that I was finding that ./configure detected SSL just fine targeting level 21, which I listed because it was the most backwards compatible API level with compiler wrappers in the current NDK. This matters because HAVE_GETIFADDRS was added in API level 24 and there are enough Android devices using older OSs, that I think people may well want to target back to at least 21.

P.P.S. What originally brought me to the doc was to create a cross-platforms set of build scripts for libcurl for Bazel, which is an increasingly popular build system from Google. Lots of folks have been spinning up Bazel BUILD files for libcurl online, mostly copying tensorflow's (fairly buggy) ones. Since those all looked problematic, I figured I'd take a shot at writing an improved set. If you'd be open to accepting my good set of Bazel BUILD files, please let me know! The advantage would be stupid easy (incremental) builds across platforms, making libcurl easily usable by Bazel users.

P.P.P.S :) Just to confirm a hypothesis: It's the need to support older compilers that prevents all the HAVE_[whatever]_H macros from being converted to __has_include's, right?