Don't break curses applications in terminalHasColors()

[osandov]

Summary

terminalHasColors() reinitializes curses every time it is called,
which breaks curses applications. For example, bcc was seeing Python
curses crashes in https://github.com/iovisor/bcc/pull/615, and GNU
readline is broken by llvm::SMDiagnostic::print() in my own project:
https://github.com/osandov/asmase/issues/1.

Instead of reinitializing curses every time we check for colors, only do
it if curses hasn't already been initialized. For that, we can check
cur_term, the global variable which is set up by curses when
newterm() or setupterm() is called.

[osandov]

Rebase. @chandlerc, could you please take a look?

lib/Support/Unix/Process.inc

unsigned Process::StandardErrColumns() {
 
   return getColumns(2);
 }
 
 #ifdef HAVE_TERMINFO
 // We manually declare these extern functions because finding the correct
 // headers from various terminfo, curses, or other sources is harder than
 // writing their specs down.
+extern struct term *cur_term;
 extern "C" int setupterm(char *term, int filedes, int *errret);
-extern "C" struct term *set_curterm(struct term *termp);
-extern "C" int del_curterm(struct term *termp);
 extern "C" int tigetnum(char *capname);
 #endif
 
 #ifdef HAVE_TERMINFO
 static ManagedStatic<sys::Mutex> TermColorMutex;
 #endif
 
 static bool terminalHasColors(int fd) {
 #ifdef HAVE_TERMINFO
   // First, acquire a global lock because these C routines are thread hostile.
   MutexGuard G(*TermColorMutex);
 
   int errret = 0;
-  if (setupterm((char *)nullptr, fd, &errret) != 0)
+  if (!cur_term && setupterm(nullptr, fd, &errret) != 0)
     // Regardless of why, if we can't get terminfo, we shouldn't try to print
     // colors.
     return false;
 
   // Test whether the terminal as set up supports color output. How to do this
   // isn't entirely obvious. We can use the curses routine 'has_colors' but it
   // would be nice to avoid a dependency on curses proper when we can make do
   // with a minimal terminfo parsing library. Also, we don't really care whether
   // the terminal supports the curses-specific color changing routines, merely
   // if it will interpret ANSI color escape codes in a reasonable way. Thus, the
   // strategy here is just to query the baseline colors capability and if it
   // supports colors at all to assume it will translate the escape codes into
   // whatever range of colors it does support. We can add more detailed tests
   // here if users report them as necessary.
   //
   // The 'tigetnum' routine returns -2 or -1 on errors, and might return 0 if
   // the terminfo says that no colors are supported.
-  bool HasColors = tigetnum(const_cast<char *>("colors")) > 0;
-
-  // Now extract the structure allocated by setupterm and free its memory
-  // through a really silly dance.
-  struct term *termp = set_curterm((struct term *)nullptr);
-  (void)del_curterm(termp); // Drop any errors here.
-
-  // Return true if we found a color capabilities for the current terminal.
-  if (HasColors)
-    return true;
+  return tigetnum(const_cast<char *>("colors")) > 0;
 #endif
 
   // Otherwise, be conservative.
   return false;
 }
 
 bool Process::FileDescriptorHasColors(int fd) {
   // A file descriptor has colors if it is displayed and the terminal has