Add plant listener instruction

[zippy]

This involves the following:

1. specifying which scape you are listening to (i.e. what state change you want to match against)
2. having a listeners scape for the scape cascade to check against so that listeners can be notified when states change. This scape probably also holds the return path information.
3. adding a processing thread into the accumulator code (or throwing this into the main accumulator thread for now, but at least modularizing the function for it) to run the cascade and trigger listening results.
4. params for plant listener:
   • semtrex for matching on the scape
   • action to reduce to be sent as the response.
   • end condition (i.e. is this a persistent or one time request, i.e. some code) Note, one time requests might not make it to the listener scape.
   • Return path (listener identification (i.e. network address) and request id, etc)

[zippy]

We should probably rename the current "listeners" code to "expectations" or something like that to not confuse the two different ways we have pending semtrex matching, one on the flux placed there by receptor designers, vs, listeners that are planted on scapes by other receptors via protocols. Actually we need a word for the combination of an expectation/action pair. Plan?

[zippy]

230b23d07f adds LISTEN instruction, which currently adds a listener to the flux. This should be expanded to have listening source for Event log or Scape too.

[zippy]

closed and split up un-done stuff into separate tickets.

[zippy]

btw as of 632fce5b16b0a9d9cd we did the renaming of listener -> expectation