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.

[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]

So, to double check: we're enforcing lexicographical order of SpecSignatures in TypeSpecializationMap. Maybe we should put signatures with less arguments first? Not sure if this would matter much.

[vlstill]

Nothing depends on the order, except that it has to be a total order for the sake of std::map. The insertion order is always driven by the "dependencies" that have to be defined first, and only when they are met for multiple elements then the order of the TypeSpecializationMap::map decides -- and even then I've left this to be ordered_map to make the order invariant on renaming of types. There is probably a better way to do this, but maybe that can be investigated in #5139.

[asl]

Yeah. My point is that with cstring:operator< we order everything lexicographically. But maybe we do not need to perform that amount of string comparisons.

[asl]

@vlstill Looks like generic-struct.p4 is failing