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.