build: improve libedit handling for builds

[compnerd]

Use the FindLibEdit.cmake module from LLDB to properly control where
the libedit libraries are searched for and linked from as well as where
the headers come from. This uses the standard mechanisms which allows
users to control where libedit is pulled from (which is important for
cross-compilation).

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

[compnerd]

CC: @jrose-apple @gottesmm @Rostepher @akyrtzi

[compnerd]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6aafad63fc10e7b23ef5c30fb3794fc5f0d67e46

[compnerd]

@swift-ci please test macOS platform

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6aafad63fc10e7b23ef5c30fb3794fc5f0d67e46

[jrose-apple]

HAVE_UNICODE_LIBEDIT was specifically checking for a libedit that supports Unicode. I don't see where the replacement code is doing that?

[compnerd]

Hmm, I didn't see anything in libedit that implied that the w* versions were optional. Did I miss something?

[jrose-apple]

Maybe there was a really old libedit lying around on an older macOS, and then we copied this forward without thinking about it. If @akyrtzi isn't worried then I guess it's fine (but then we should not bother having two names for whether or not it's available).

[compnerd]

Unfortunately, we do need two names for it - the preprocessor macro shouldn't use the CMake naming. CMake uses <package>_FOUND while the preprocessing side tends to use HAVE_<package>. Or perhaps I misunderstood the two names that you are referring to? I'm happy to rename HAVE_UNICODE_LIBEDIT to HAVE_LIBEDIT though if you would like.

[compnerd]

@swift-ci please test macOS platform

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6aafad63fc10e7b23ef5c30fb3794fc5f0d67e46

[jrose-apple]

Oh, I didn't think about the fact that the second CMake name was still needed for configure_file. I do think the rename is a good idea but that's less important.

[compnerd]

@swift-ci please test macOS platform

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6aafad63fc10e7b23ef5c30fb3794fc5f0d67e46

[compnerd]

@swift-ci please test macOS platform

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6aafad63fc10e7b23ef5c30fb3794fc5f0d67e46

[compnerd]

@swift-ci please test macOS platform

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6aafad63fc10e7b23ef5c30fb3794fc5f0d67e46

[compnerd]

@swift-ci please test macOS platform

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 6aafad63fc10e7b23ef5c30fb3794fc5f0d67e46

[compnerd]

@swift-ci please test

[beccadax]

I think this change may have broken the build on our 14.04 bots:

05:14:24 lib/libswiftImmediate.a(REPL.cpp.o):/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/lib/Immediate/REPL.cpp:function swift::runREPL(swift::CompilerInstance&, std::vector<std::string, std::allocator<std::string> > const&, bool): error: undefined reference to 'el_wgets'
05:14:24 lib/libswiftImmediate.a(REPL.cpp.o):/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/lib/Immediate/REPL.cpp:function swift::runREPL(swift::CompilerInstance&, std::vector<std::string, std::allocator<std::string> > const&, bool): error: undefined reference to 'el_wgets'