Fix bugs in several Yosys cell implementations

[chameco]

Several SAW implementations of the semantics of Yosys cells did not match the expected behavior. This PR hopefully fixes a few instances of this (there are undoubtedly more). I also refactored out some duplicated code for e.g. handling bit order - this is a common source of error in the semantics, as the convention in SAWCore is opposite Yosys.

Longer-term, we should ensure that we have good reason to trust these cell definitions - if they're incorrect, we're not reasoning about anything useful! I think at least some randomized testing would be a good start, and I plan to implement something to address this in the future. #1816 tracks this need.

[RyanGlScott]

Out of curiosity, what were the actual buggy parts of the code? (It's somewhat hard to tell due to all of the adjacent refactorings in the diff.)

[chameco]

Specifically, the issues were:

• the logic_not cell was producing SAWCore that did not typecheck (an incorrect width was being passed to bvNonzero)
• another incorrect width was being used in the reduce_* cells
• incorrect endianness with the bitwise shift cells (shl etc.)
• the shiftx and pmux cells were unimplemented

[RyanGlScott]

Ah, OK. Part of me wonders if we should always call flipEndianness before calling each operation to avoid issues like this in the future, but then again, that would impose an additional simulation-time cost. In lieu of that, perhaps it is worth grouping up the operations in the code that are sensitive to the endianness so that is easier to tell them apart.

I don't have much insight into the rest of the code, so my approval here is mostly a formality :)

[chameco]

Ah, OK. Part of me wonders if we should always call flipEndianness before calling each operation to avoid issues like this in the future, but then again, that would impose an additional simulation-time cost.

Yeah, I thought about this, but the term size increase scared me off (in addition to simulation time, I find myself reading parts of the resulting SAWCore terms quite often, and lots of redundant reverses make that obnoxious). There are probably some relatively easy solutions but for now ¯\_(ツ)_/¯. I think the larger problem in any case is the lack of more exhaustive testing, which I hope to address in the (near?) future.

Thanks for the review!