Add initial implementation for BMv2 headers and parsers

[PietroGhg]

This PR adds an initial implementation for BMv2 Headers and Parser. Only a few parsing constructs are supported, more will be added with follow up PRs.
In order to match the BMv2 json spec, transitions, transition keys and parsing operations are split into three separate regions (with appropriate checks in the verifier) that resemble the final json nodes that we want to emit.

[asl]

See first round of comments

[asl]

So we cannot extract to arbitrary variable? E.g.

bit<32> foo;
packet_in.extract(foo);

?

How does BMV2 backend deal with that?

[PietroGhg]

For the particular example in your comment, p4c raises an error if I try to pass a bit<42> variable to extract (says only headers are allowed). If we have an header instance as a local variable, the header instance will be part of the headers JSON node, and the extract node can refer to it from there

[asl]

ok, then we'd need similar error here :)

[asl]

So, what's about the error here? Here is the place where we'd need to emit user-visible errors in case of match failures.

[PietroGhg]

Sorry I missed the comment. I've added the check for header type, although I'm not sure here it's the right place for this type of errors, maybe it's better to raise this in the front end?

[asl]

Well, this is a target-specific limitation. So it should be handled during the translation.

[PietroGhg]

Ok makes sense, we got the error message now 👍

[asl]

getStartState

[PietroGhg]

Thanks, I think I still need op.getBody().back().getTerminator() to access the actual transition op since we want to remove it from the region after retrieving the starting state

[asl]

I'd add then something like getStartTransition to the ParserOp.

[PietroGhg]

Done, thank you