Execute fragments with a MergeNode on the union of its input fragment and scan hosts.

Old union plans:
We used to construct union plans where all operands of the union
were executed concurrently. Every union operand materialized the same tuple
via a MergeNode that had a single child (root node of that particular operand).
The results of these union branches were combined via an ExchangeNode.
Assigning fragments to hosts was done as usual based on the leftmost scan or
the leftmost input fragment, i.e., the presence of a MergeNode in a fragment
did not have any impact on that scheduling decision.

New union plans:
Our new union plans produce a single fragment with a MergeNode connecting
all child fragments as its root (see commit with planner changes for details).
This strategy allows us to execute union operands serially or concurrently.
It also greatly simplifies planning as well as resource allocation, e.g., for
external sorts. Operands are currently executed serially.

Problem:
These new union plans require a different strategy for the fragment to host assignment
because MergeNodes are special in the sense that they can consume multiple partitioned
inputs, as well as execute multiple scans in the same fragment. For example,
using our current strategy, a pathological fragment to host assignment could lead to
remote reads because the leftmost scan (or input fragment) could run on fewer hosts than
other scans consumed by the same MergeNode.

Solution:
To solve this issue, fragments containing a MergeNode are executed on the union of hosts
of all scans in the fragment as well as the hosts of all its input fragments.

Change-Id: I5bf7a71a5a0fdb3b589495344d6fc8dd18d37fa7
Reviewed-on: http://gerrit.ent.cloudera.com:8080/2980
Reviewed-by: Alex Behm <alex.behm@cloudera.com>
Tested-by: jenkins
Add HS2 GetLog() test

Change-Id: I24cc4a1873942cb4d67dcf75ed57ce7becec6f11
Reviewed-on: http://gerrit.ent.cloudera.com:8080/3016
Reviewed-by: Alex Behm <alex.behm@cloudera.com>
Tested-by: jenkins