[FLINK-1017] Add documentation for execution parallelism

This closes #114
Updated documentation figure: FlinkOnYarn.svg

This closes #110
[FLINK-629] getFieldNotNull added to Tuple and updated Aggregators and Comparators to use that where appropriate
[FLINK-629] Updated getFieldNotNull usage and added it to TupleSerializers

This closes #73
[FLINK-1063] Revert race introducing commit

This reverts "[FLINK-998] Close network connections when idle" [1] as
it introduced a race condition into the network stack, which might
result in a re-ordering of network envelopes.

[1] 52512636444902497e47ccbfb1cabaffb3e23343
[FLINK-1063] Add non-multiplexing NetworkConnectionManager

This commit introduces a non-multiplexing NetworkConnectionManager. The
default system behaviour is to multiplex multiple logical channels over
the same TCP connection.

This behaviour can now be configured via the configuration key:
    taskmanager.net.multiplexConnections (default: true)

Background:

When translating a JobGraph to an ExecutionGraph, edges are assigned
connection indexes to ensure deadlock freedom of the network stack.
Deadlocks can easily occur when multiplexing multiple logical channels
over a single TCP connection, because of the limited network buffers.
Each incoming envelope, which has an attached buffer, needs to request
a network buffer from the receiver's input buffer pool. If the receiver
does not have a buffer available, it unsubscribes from the TCP
connection until a new buffer is available. This unsubscribe then
affects all other logical channels, which are multiplexed over the same
TCP connection. With certain user programs this can result in a
deadlock.

One of the problems when running in multiplexed mode is the question of
when to close TCP connections in a reliable way without loosing or
re-ordering network envelopes (as evident in the reverted [1]). In
non-multiplexed mode this is trivial, because every logical channel is
mapped to a phyiscal channel and the close of the logical channel
translates to a close of the physical channel.

[1] 52512636444902497e47ccbfb1cabaffb3e23343
Possible fix for deadlock