We do not differentiate between `reg`s with the same name across different scopes

regfile modules_l_reset_0 {
    default regwidth = 8;
    reg {
        field {} PORT7[7:7] = 0;
        field {} PORT6[6:6] = 0;
        field {} PORT5[5:5] = 0;
        field {} PORT4[4:4] = 0;
        field {} PORT3[3:3] = 0;
        field {} PORT2[2:2] = 0;
        field {} PORT1[1:1] = 0;
        field {} PORT0[0:0] = 0;
    } MOD_L;
};

regfile modules_l_reset_1 {
    default regwidth = 8;
    reg {
        field {} PORT7[7:7] = 1;
        field {} PORT6[6:6] = 1;
        field {} PORT5[5:5] = 1;
        field {} PORT4[4:4] = 1;
        field {} PORT3[3:3] = 1;
        field {} PORT2[2:2] = 1;
        field {} PORT1[1:1] = 1;
        field {} PORT0[0:0] = 1;
    } MOD_L;
};

Both of these regs have the same name, but different reset values. When they are instantiated, the first one parsed has code generated while any that follow are ignored. We could solve this by bringing in another level of the hierarchy into the naming (i.e. modulesLReset0ModL and modulesLReset1ModL rather than the current ModL), but then the names continue to balloon in size. The workaround here is to just name the regs differently, but that is going to be unsustainable long term.

No source files, tests, or entry points are identified in the issue. Start by reproducing the two regfile example and tracing how scoped reg names are resolved during code generation. Done means same-named regs in different scopes both generate code with distinct identities without requiring unnecessarily long manual names.