Create different InsnTest cases for non-combinational mem + pipelined CPU

[jardhu]

Right now, since the tests were built with only combinational memory on hand, the InsnTests assume that the CPUs use combinational memory. This poses a problem for testing the pipelined CPU with the non-combinational memory. Since these are delayed the execution of these tests inherently lasts longer, and the short cycle count the tests dedicate to the simulator do not allow the CPUs to finish execution.

To remedy this, the testing suites should be revised to include a combinational and non-combinational memory section, which assigns the memType and memPortType parameters in the configuration file appropriately. This will permit the tester drivers to thoroughly test the non-combinational pipelined + pipelined with branch predictor CPU models.

I do not know if there is an exact formula that determines how many cycles the non-combin pipeline should take, though after messing with CPUTesterDriver I found that multiplying the number of combin cycles by the delay suffices for all of the tests to complete.

[powerjg]

We need to think about whether we want to figure out the exact number of cycles or not... I like the idea of encoding the exact number of cycles in the tests as I think it will capture more bugs. However, this makes the tester quite complicated.