[design] Support for incremental parsing

[chkim4142]

There has been concerns that allowing any parsers or control flows to call any other parsers or control flows (irrespective of whether they belong to ingress or egress) might lead to a P4 coding style that is supportable only a certain type of machines. If we want P4 to be widely applicable, we should error on the conservative side.

To enable both pipeline-style targets and CPU/NPU-style targets, the group felt the following approach would be reasonable. Note #1 and #2 below are already possible with the current P4 spec. Only #3 is a new feature.

1. Allow exiting a parser through multiple exit points, each of which can lead to a different control flow
2. Allow a control flow to call other sub-control flows. Although currently the egress must start with one pre-defined fixed entry point (which is "egress"), one can quickly branch out and call multiple sub-control flows from there.
3. Allow a control flow to call a parser via resubmit() or continue_parsing(). The current spec doesn't define the semantics of resubmit() -- it doesn't tell whether resubmit() resets the parse pointer of the resubmitted packet to zero or retains the last position where parsing exited. We should make it clear (the former way) in the spec and should consider introducing another primitive action called continue_parsing(), which retains the last position where parsing stopped.

[chkim4142]

This is one of the key motivations for P4_16. Separating architecture from language enables this.