Implemented the ability to execute any postprocess provided by the plugin after each instruction

[kseniadobrovolskaya]

Here is the easiest way to add the agnostic behavior discussed in this issue: Implementation of a special case of an agnostic element behavior policy #2061

Added extensions to implement:
1. Mask agnostic behavior of filling with 1s - xspikema1s
2. Tail agnostic behavior of filling with 1s - xspiketa1s

[kseniadobrovolskaya]

@aswaterman, take a look please

[arromanoff]

Instruction post-processing LGTM. I'd like someone else to take a look as well

[arromanoff]

@aswaterman, @nibrunieAtSi5 Could you review this please?

[aswaterman]

I have a few issues with this approach. First, it adds several instructions to the critical execution path--even iterating over an empty list on every instruction materially slows down the simulator. Whatever we do shouldn't have a performance effect on instructions that don't use the feature.

Second, although I am sympathetic to the desire to model a wider variety of implementation-defined behaviors, I'm not convinced that the pattern of a postprocessing hook is either necessary or sufficient to meet our needs. It does work OK for this particular case, but it's more general than necessary for this case. And still, there are other cases for which it doesn't suffice.

Defining a custom extension to modify this behavior does make sense to me, but the way I'd do it is to have the custom instructions redefine these instructions, rather than adding a hook. (Recall, custom extensions in Spike can redefine standard opcodes, since custom extensions are always searched first for an opcode match.) This approach also has the advantage of not requiring any Spike modifications.