apps: Use existing type synonyms consistently

portId is currently a synonym for a VInt.t but that will likely change
at some point to be a synonym for int64. Use the type consistently here,
which may save time later.
apps: Define basic types that apps will use

This commit includes two important type definitions:

  * event - describes the types of events that frenetic applications
    will be exposed to, and will be expected to handle in some way.

  * result - the ultimate result of a frenetic application. A list of
    packet_outs to send to various switches, as well as the new policy
    that should be installed on those switches. It's on this type that
    sequence and union will be defined, and then lifted to a function type.
apps: async interface and combinators

For all intents and purposes, Async_NetKAT.mli is a specification of the
Frenetic application API.

Closes #244.
apps: implementation of netkat async controller
from_pipe: rename seq_act to seq_act_t

The name did not imply that there was anything else being sequenced. Now
it implies that after the action, the type of the module the function
belongs to is also being sequenced.
from_pipe: Add matches operation to relevant modules

matches determines whether or not some pattern-like structure matches a
given packet.
from_pipe: Determine the pipe from which a packet came

from_pipe takes a Local.t, which a controller may cache per switch, and
a packet, and determines the pipe that the packet belongs to. In general
this is not always possible. For a brief interval during switch setup,
packets may be sent to the controller not due to a policy. If a policy
makes use of different pipe name in non-disjoint parallel compositions,
then it may come from either, in which case the pipe the packet belongs
to is ambiguous.
from_pipe: Return all matching pipe

The user may have composed two applications that are interested in
packets that match identical filters, but are sent to different pipes.
from_pipe must account for this, and therefore return all pipes that
match the packet. It is the job of the runtime to then deliver the
packets to the proper pipe within the application, when possible.
core_map: Use Core_map in Semantics
(cherry picked from commit 434b1f8c900f2b3e46fe2f03782db5e5f7b0cabb)
from_pipe: Use Semantics to determine pipes

The from_pipes function now assumes that packets are not modified on the
switch before being sent to the controller. That means that any
modification of a field preceding a "port := <pipe>" is ignored for the
purposes of compilation, and implemented at the controller.
from_pipe: Preserve location in returned packets

Not sure why the code was clearing it before.
from_pipe: Properly compile pipe location assignment

Any action that involves "port := <pipe>" should skip all other
modifications, and send the packet straight to the controller. The
skipped modifications will be applied there.
from_pipe: Properly compile location filter

Skip filters that match on pipes.
from_pipes: apply semantics in Controller

When the controller receives a packet, it uses a cached representation
of the policy installed on the switch to determine which pipe it should
be sent to.
from_pipe: Add eval to LocalCompiler

Previously called from_pipes. This function will evaluate a packet on a
switch's policy, returning two lists. The first contains pairs of pipe
names and modified packets. These will be sent to listening
applications. The second is a list of modified packets. These will be
used to generate packet out messages.
from_pipe: Handle eval'd packets at physical locations

When a packet arrives at the controller, it's eval'd given the policy
currently installed on the switch. If that produces packets located at
physical locations, the controller will generate packet outs that will
perform the appropriate modifications in the form of actions.

Previously, the packet was not modified and no actions were inclued with
the packet_out.
Fix bug in mk_ethType

Was actually setting vlanPcp
from_pipe: fix bug in LocalCompiler.set_to_action

Due to the flattening of seqs that involve Controller actions, this
function may now produce duplicates. So, deduplicate. This approach does
not preserve the order of the pars.
from_pipe: Implement packet modification in controller

Right now, the compiler will not generates rules to modify packets if
they'll ultimately be sent to the controller. It's up to the controller
to implement those changes, which must happen before passing packets to
the application.
from_pipe: remove unused port in packet_out

The port optional port in a OFPT_PACKET_OUT is only used when the action
list contains an action that would send the packet to the TABLE
pseudoport. As of now, Frenetic does not allow this.