Cache more than one packet in the flow hold queue (3 to be precise)

The main problem with caching more than one packet is the race between
forwarding paths adding new packets and agent flushing them in a different
core. One way this can be solved is by deferring the flushing till all
cores have seen the change of the flow state. However, this adds to latency.
Adding a spinlock (the only lock that is possible) is not preferrable
since it is possible that one of the forwarding thread can be looping on
the lock availability.

The way we fix this is by doing a bit of compromise. We run a two stage
flush. In the first stage, which happens when agent has changed the state,
we take all packets that were queued before agent changed the state (
thus solving the latency) and in the second stage that runs in a defer, we
take care of all those packets that were queued at the same moment the flow
entry was changing state, but did not see the change. It is possible that
we will see some latency for these packets and a possible reorder, but till
we observe and conclude that this latency indeed occurs and we can't live with
the anomaly, this solution seems to be the best.

This change also simplifies flow queue alloction and free by making the queue
an array instead of a list.

Many of the files that show up in the commit have a header file inclusion
since we had to remove one inclusion from vrouter.h.

Closes Bug:#1387710

Change-Id: I4d08fc96d6d154f1bcdace1860c51982a324cdd9