Labels generated by relooper can differ between platforms

[randomPoison]

With the new relooper algorithm (#1558) c2rust now generates labeled blocks/loops/breaks, but the exact label names used are platform dependent. This specifically came up as a difference between our linux and macos runs in CI.

Example code that translates differently between linux and macos

switch (x)
{
case 0:
    x += 1;
case 1:
    x += 1;
case 2:
    x += 1;
case 3:
    x += 1;
default:
    x += 1;
}

Linux translation:

'c_175: {
    'c_174: {
        'c_173: {
            match x {
                0 => {
                    x += 1 as ::core::ffi::c_int;
                }
                1 => {}
                2 => {
                    break 'c_173;
                }
                3 => {
                    break 'c_174;
                }
                _ => {
                    break 'c_175;
                }
            }
            x += 1 as ::core::ffi::c_int;
        }
        x += 1 as ::core::ffi::c_int;
    }
    x += 1 as ::core::ffi::c_int;
}
x += 1 as ::core::ffi::c_int;

Macos translation:

'c_280: {
    'c_279: {
        'c_278: {
            match x {
                0 => {
                    x += 1 as ::core::ffi::c_int;
                }
                1 => {}
                2 => {
                    break 'c_278;
                }
                3 => {
                    break 'c_279;
                }
                _ => {
                    break 'c_280;
                }
            }
            x += 1 as ::core::ffi::c_int;
        }
        x += 1 as ::core::ffi::c_int;
    }
    x += 1 as ::core::ffi::c_int;
}
x += 1 as ::core::ffi::c_int;

The issue appears to specifically be the unnamed labels that come from the C compiler (the 'c_xxx labels). If the issue is just that the compiler generates different numeric IDs on different platforms, then we can probably fix this by applying our own platform-independent numbering, e.g. by doing a traversal of the CFG and numbering the nodes in the order we visit them (though that may not be the ideal ordering). If the CFG itself is actually different between platforms, e.g. if it has a different number of nodes, then addressing this issue may be more difficult.

[randomPoison]

Ah, this also affects the values we generate for current_block, because those are also derived from the CFG labels.

[fw-immunant]

Could we name these after the corresponding line number in the original C, with an additional disambiguator if there are multiple? Doing so would provide additional hints to the reader and should be platform-independent. If the disambiguation is done at the time of generating the Rust AST, it should be able to match as long as the generated AST otherwise matches.

[randomPoison]

In the example case above I think the nicer naming would be to use the switch case labels, per #1526. I think that would be enough to ensure that all labels we generate have meaningful names, since the only times we can get labeled blocks are gotos (where we already have a meaningful label) and switch-with-fallthrough. If I'm wrong about that and there are other times where labels show up, then using line numbers might be useful.

[ahomescu]

I already ran into this and fixed it in one place 3819cdd, so I agree that yeah we shouldn't use the CStmtIds or other ids that we get from clang.