[lit] Update local test objects "in place" from remote test objects

Update local test object "in place" from remote test object.  We need to
do this to ensure that discovered test object which is used for printing
test results reflect the changes.

> Why are we sending back the whole test object from the worker process
> (lit.worker.execute) instead of just the result?

Unfortunately, the test result is not the only "result" of test
execution.  Other members (e.g., xfails, requires) of the Test class are
set only during execution.  Those members affect the behavior of
`isExpectedToFail` and `setResult`, and are accessed when printing
results.  For example, xunit.xml test results include missing features
for "skip reasons".  The lack of separation between an immutable "test
definition" and "generated outputs" (including the primary result and
other secondary state) is unfortunate historical design decision in lit.

> Why do we update the initial test object instead of just discarding it
> and continuing with the pickled test object?

Both of these approaches would work.  However, note that we need a fully
populated test object for printing results.  Updating the existing one
seems to be the easier path.

llvm/utils/lit/lit/run.py

@@ -91,12 +91,18 @@ class Run(object):
             except multiprocessing.TimeoutError:
                 raise TimeoutError()
             else:
-                self.tests[idx] = test
+                self._update_test(self.tests[idx], test)
                 if test.isFailure():
                     self.failures += 1
                     if self.failures == self.max_failures:
                         raise MaxFailuresError()
 
+    # Update local test object "in place" from remote test object.  This
+    # ensures that the original test object which is used for printing test
+    # results reflect the changes.
+    def _update_test(self, local_test, remote_test):
+        local_test.__dict__.update(remote_test.__dict__)
+
     # TODO(yln): interferes with progress bar
     # Some tests use threads internally, and at least on Linux each of these
     # threads counts toward the current process limit. Try to raise the (soft)