Once again we've been bitten by comparison failure between "c:\somepath" and
"C:\somepath". Normalize paths in both Python helper scripts to make that
comparison more robust.

Apparently something in the Linux system header chain #defines a macro Status
as 'int'. That's just Bad in C++ land. It should at the very least be a
typedef! #undefining it in llprocess.h permits the viewer to build.

Include logic to engage Linden apr_procattr_autokill_set() extension: on
Windows, magic CreateProcess() flag must be pushed down into apr_proc_create()
level. When using an APR package without that extension, present
implementation should lock (e.g.) SLVoice.exe lifespan to viewer's on Windows
XP but probably won't on Windows 7: need magic flag on CreateProcess().
Using APR child-termination callback requires us to define state (e.g.
LLProcess::RUNNING). Take the opportunity to present Status, capturing state
and (if terminated) rc or signal number; but since most of the time all caller
really wants is to log the outcome, also present status string, encapsulating
logic to examine state and describe exited-with-rc vs. killed-by-signal.
New Status logic may report clearer results in the case of a Windows child
process killed by exception.
Clarify that static LLProcess::isRunning(handle) overload is only for use when
the original LLProcess object has been destroyed: really only for unit tests.
We necessarily retain our original platform-specific implementations for just
that one method. (Nonstatic isRunning() no longer calls static method.)
Clarify log output from llprocess_test.cpp in a couple places.

Windows 7 and friends tend to create a process already implicitly allocated to
a job object, and a process can only belong to a single job object. Passing
CREATE_BREAKAWAY_FROM_JOB in CreateProcessA()'s dwCreationFlags seems to
bypass the access-denied error observed with AssignProcessToJobObject()
otherwise.
This change should (!) enable OS lifespan management for SLVoice.exe et al.

On Posix, these and the corresponding getProcessID()/getProcessHandle()
accessors produce the same pid_t value; but on Windows, it's useful to
distinguish an int-like 'id' useful to human log readers versus an opaque
'handle' for passing to platform-specific API functions. So make the
distinction in a platform-independent way.

On Posix platforms, the OS argument mechanism makes quoting/reparsing
unnecessary anyway, so this only affects Windows.
Add optional 'triggers' parameter to LLStringUtils::quote() (default: space
and double-quote). Only if the passed string contains a character in
'triggers' will it be double-quoted.
This is observed to fix a Windows-specific problem in which plugin child
process would fail to start because it wasn't expecting a quoted number.
Use LLStringUtils::quote() more consistently in LLProcess implementation for
logging.

That is, we try to pass through each args entry as a separate child-process
arvg[] entry, whitespace and all.

If LLProcess can't set the right flag on a Windows Job Object, the object
isn't useful to us, so we might as well discard it.
quote() is sufficiently general that it belongs in LLStringUtil instead of
buried as a static helper function in llprocess.cpp.

Much as I dislike viewer log spam, seems to me starting a child process,
killing it and observing its termination are noteworthy events.
New logging makes LLExternalEditor launch message redundant; removed.

The idea is that, with the right flag settings, this will cause the OS to
terminate remaining viewer child processes when the viewer terminates --
whether or not it terminates intentionally. Of course, if LLProcess's caller
specifies autokill=false, e.g. to run the viewer updater, that asserts that we
WANT the child to persist beyond the viewer session itself.

Using a Params block gives compile-time checking against attribute typos. One
might inadvertently set myLLSD["autofill"] = false and only discover it when
things behave strangely at runtime; but trying to set myParams.autofill will
produce a compile error.
However, it's excellent that the same LLProcess::create() method can accept
either LLProcess::Params or a properly-constructed LLSD block.

This allows callers to pass either LLSD formatted as before -- which all
callers still do -- or an actual LLProcess::Params block.

LLProcessLauncher had the somewhat fuzzy mandate of (1) accumulating
parameters with which to launch a child process and (2) sometimes tracking the
lifespan of the ensuing child process. But a valid LLProcessLauncher object
might or might not have ever been associated with an actual child process.
LLProcess specifically tracks a child process. In effect, it's a fairly thin
wrapper around a process HANDLE (on Windows) or pid_t (elsewhere), with
lifespan management thrown in. A static LLProcess::create() method launches a
new child; create() accepts an LLSD bundle with child parameters. So building
up a parameter bundle is deferred to LLSD rather than conflated with the
process management object.
Reconcile all known LLProcessLauncher consumers in the viewer code base,
notably the class unit tests.

moved LLInitParam, and LLRegistry to llcommon
moved LLUIColor, LLTrans, and LLXUIParser to llui
reviewed by Nat

Despite LLProcessLauncher's list-of-argument-strings API, on Windows it must
ram them all into a single command-line string anyway. This means that if
arguments contain spaces (or anything else that would confuse Windows command-
line parsing), the target process won't receive the intended arguments.
Introduce double quotes for any arguments not already double-quoted by caller.

Apparently our TeamCity build machines are still not up to Python 2.6.

typedef LLProcessLauncher::ll_pid_t to be HANDLE on Windows, pid_t elsewhere.
Then we can define getProcessID() returning ll_pid_t on all platforms,
retaining getProcessHandle() for hypothetical existing consumers... of which
there are none in practice.
This lets us define isRunning(ll_pid_t) to encapsulate the platform-specific
logic to actually check on a running child process, turning non-static
isRunning() into a fairly trivial wrapper.

Instead of free python() and python_out() functions containing a local
temporary LLProcessLauncher instance, with a 'tweak' callback param to
"do stuff" to that inaccessible object, change to a PythonProcessLauncher
class that sets up a (public) LLProcessLauncher member, then allows you to
run() or run() and then readfile() the output. Now you can construct an
instance and tweak to your heart's content -- without funky callback syntax --
before running the script.
Move all such helpers from TUT fixture struct to namespace scope. While
fixture-struct methods can freely call one another, introducing a nested class
gets awkward: constructor must explicitly require and bind a fixture-struct
pointer or reference. Namespace scope solves this.
(Truthfully, I only put them in the fixture struct originally because I
thought it necessary for calling ensure() et al. But ensure() and friends are
free functions; need only qualify them with tut:: namespace.)

Run INTEGRATION_TEST_llprocesslauncher using setpython.py so we can find the
Python interpreter of interest.
Introduce python() function to run a Python script specified using
NamedTempFile conventions.
Introduce a convention by which we can read output from a Python script using
only the limited pre-January-2012 LLProcessLauncher API. Introduce
python_out() function to leverage that convention.
Exercise a couple of LLProcessLauncher methods using all the above.

On a Posix platform (vfork()/execv() implementation), if for any reason the
execv() failed (e.g. executable not on PATH), the viewer would never know, nor
the user: the vfork() child produced no output, and terminated with rc 0! Add
logging, make child terminate with nonzero rc.
Remove pointless addArgument(const char*) overload: this does nothing for you
that the compiler won't do implicitly.
In llupdateinstaller.cpp, remove pointless c_str() call in addArgument() arg:
we were starting with a std::string, then extracting its c_str(), only to
construct a whole new std::string from it!

Specifically:
Introduce ManageAPR class in indra/test/manageapr.h. This is useful for a
simple test program without lots of static constructors.
Extract NamedTempFile from llsdserialize_test.cpp to indra/test/
namedtempfile.h. Refactor to use APR file operations rather than platform-
dependent APIs.
Use NamedTempFile for llprocesslauncher_test.cpp.

Add unit tests to verify basic functionality.

Defend test against the ambiguous answer to that question by not recording, or
testing for, EOF history events.
Enrich output for history-verification failures: display whole history array.

Previous logic was vulnerable to the case in which both pipes reached EOF in
the same loop iteration. Now we use std::list instead of std::vector, allowing
us to iterate and delete with a single pass.

Otherwise the unreferenced declaration causes a fatal warning.

Quiet the temporary child_status_callback() output.
Add a bit of diagnostic info if apr_proc_wait() returns anything but
APR_CHILD_DONE.

At least on OS X 10.7, a call to apr_proc_wait(APR_NOWAIT) in fact seems to
block the caller. So instead of polling apr_proc_wait(), use APR callback
mechanism (apr_proc_other_child_register() et al.) and poll that using
apr_proc_other_child_refresh_all().
Evidently this polls the underlying system waitpid(), but the internal call
seems to better support nonblocking. On arrival in the
child_status_callback(APR_OC_REASON_DEATH) call, though, apr_proc_wait()
produces ECHILD: the child process in question has already been reaped.
The OS-encoded wait() status does get passed to the callback, but then we have
to use OS-dependent macros to tease apart voluntary termination vs. killed by
signal... a bit of a hole in APR's abstraction layer.
Wrap ensure_equals() calls with a macro to explain which comparison failed.

Fix EOL issues: "\r\n" vs. "\n".
On Windows, requesting a read in nonblocking mode can produce EAGAIN instead
of EWOULDBLOCK.