Do not print confusing warning when a parser state contains an assignment to an l-value slice

[kfcripps]

I don't think it makes sense to print a warning about an l-value being uninitialized when either the entire l-value or a slice of said l-value is written to.

On main branch, the added P4 program results in:

$ p4test tmp.p4 --dump t --loopsUnroll
tmp.p4(9): [--Wwarn=uninitialized_use] warning: s.f may be uninitialized
        s.f[3:0] = 2;
        ^^^
tmp.p4(9): [--Wwarn=ignore-prop] warning: Result of 's.f[3:0] = 4w2' is not defined: Error: Uninitialized
        s.f[3:0] = 2;
                 ^

and on this branch:

$ p4test tmp.p4 --dump t --loopsUnroll
tmp.p4(9): [--Wwarn=uninitialized_use] warning: s.f may be uninitialized
        s.f[3:0] = 2;
        ^^^

Ideally both warnings would be gotten rid of, but I don't know how to get rid of the first one, and the second one is the most confusing to me. This is at least an improvement over the previous behavior. I am open to suggestions if anyone has any ideas of how to get rid of the first warning also.

[kfcripps]

The fact that this warning is worded this way is not great - I opened #4945 to improve this and similar warnings

[fruffy]

It makes sense to print a warning if only parts of the lvalue are written to but I agree, if we are assigning to the whole slice this warning is unnecessary.

On that note, which passes require this interpreter? It is rather hard to maintain and produces lots of confusing warnings like this one.

[fruffy]

The warning itself occurs in the parserUnroll pass. I think to get rid of it you need to insert some logic to check that the slice being assigned properly. We can also fix the warning there.