frontend: Fix SpecializeGenericTypes

[vlstill]

A significant rewrite of SpecializeGenericTypes. Namely it fixes problems occurring in more complex specializations where a specialized type might depend on another specialized type and their order of insertion can be incorrect. Instead the types are now inspected to check for their dependencies and inserted just after all of the dependencies. I've also change the naming scheme of the specializations so that simple once are more readable (although for complex once the types quickly becomes ugly).

A caveat is that many passes seem to use very similar, but slightly different patterns and these passes still contain bugs (e.g. EliminateTuples. SpecializeGenericFunctions). Ideally, we would want to factor out the common parts and implement only the specific once, but I don't have time for that (at least not now). Namely at least the insertion part should be factorable for any pass that inserts global objects that can have dependencies.

Without the changes, the added test fails with

1217: Error compiling
1217: In file: ./p4c/frontends/p4/typeChecking/typeChecker.cpp:144
1217: type-spec-nested.p4(3): Could not find type of <Type_Struct>(3478) S2_0/2 struct S2_0 {
1217:   int<6> x;
1217:   int<6> y; }
1217: struct S2<T> {
1217:        ^^

The reason is that the specialization of S2 is inserted after specialization of S1 which refers to it.

fixes #4835

[vlstill]

@fruffy or anyone familiar with Bazel, any idea what is behind the bazel failure (e.g. here)? I can see it did not find absl/strings/str_replace.h, but I don't know how to find it as there is no @com_google_absl//absl/strings:str_replace.

[asl]

Overall, looks good to me. See some minor notes and questions.

[asl]

@vlstill Looks like generic-struct.p4 is failing

[vlstill]

@vlstill Looks like generic-struct.p4 is failing

Yep, there was still some dependency on processing order, it should now be fixed hopefully.

[vlstill]

The ptf-ebpf failure seems unrelated, likely a missing dependency (I don't see why though). But this is not a required check, so we should be able to merge anyway once this is approved.

It passed after rerun.

[fruffy]

Not very familiar with that pass so it might take me a bit to give a proper review. Other might be better qualified for that.

[fruffy]

Somewhat of a nonstandard issue name for the file? Although we do not really have a consistent naming scheme.

[vlstill]

oh, sometimes I forget which conventions differ between projects, renamed to be more consistent :-)

[asl]

Great, thanks!