`next` keyword to replace `LatencyOffset` and augment `state`

As it stands, lots of bugs are caused by LatencyOffset being too simplistic of an abstraction. The main place such bugs occur is within conditional blocks, because of course the condition at '0 need not be the same as the one at 'OFFSET.

With the next keyword, we could have a condition-aware construct. next would have an optional gen int argument: next(num_nexts).

Example:

module feedback_loop#(int LATENCY) {
  output bool o'0
  
  bool pre_offset_o'LATENCY
  pre_offset_o = false
  o = LatencyOffset#(OFFSET: -LATENCY)(pre_offset_o)
  action set_o'LATENCY {
    pre_offset_o = true
  }
}

could become

module feedback_loop#(int LATENCY) {
  output bool o'0
  
  o = false
  action set_o'LATENCY {
    next(LATENCY) o = true
  }
}

Why call it next? Because we'll integrate it with state like so:
state semantics become "reading is one latency cycle removed from writing". So then writes to state are immediately transparent, unless next is used:

state int x
state int a

x = 5
int y = x      // y is 5

next a = 20
int b = a      // b is previous value of a

Finally, we can also use next together with local actions, and thereby create a sort of state machine.

local action iteration : int cur_iter {
  when ... {
    next iteration(cur_iter + 1)
  }
}

Start by tracing how LatencyOffset and state are represented and handled in the compiler. Review the existing semantics for conditional blocks and local actions, then define the implementation scope for next(num_nexts), transparent state reads, and deferred writes. Done means the examples' latency behavior and state-machine use are supported consistently.