Fix a subtle bug in causal KVS read path.

Previous coding:

    safe_read <= (read_pending * seal_read_dep_id).lefts(:id => :id).notin(missing_read_dep, 0 => :id)
    read_resp <+ (safe_read * view).pairs(:key => :key) {|r,v| [r.src_addr, r.id, r.key, v.val]}

In itself this isn't wrong; we need <+ to break the NM cycle between safe_read
and missing_read_dep. The problem arises because <+ is also used to define dom,
which in turn is used to define view:

    safe_dep <= (dep * safe).pairs(:id => :id) {|d,s| [d.id, d.target, s.key]}
    dom <+ (safe_dep * safe).lefts(:target => :id, :src_key => :key) {|d| [d.target]}.notin(dom, 0 => :id)
    view <= safe.notin(dom, :id => :id)

Because the dom derivation is postponed to @next, there is a *single* timestep
in which both the dominating and dominated writes appear in view. This is
unfortunate :-\

For now, fix this problem by pushing the safe_read derivation to @next:

    safe_read <+ (read_pending * seal_read_dep_id).lefts(:id => :id).notin(missing_read_dep, 0 => :id)
    read_resp <= (safe_read * view).pairs(:key => :key) {|r,v| [r.src_addr, r.id, r.key, v.val]}

Example: W2 dominates W1, and read R1 depends on W2. Local replica knows W1 and
R1 (which is kept in pending). When W2 is observed, it is promoted to safe in
the next timestep. In that timestep, safe_read(R1) and dom(W1) facts are both
derived *for the following timestep*. Hence, once the read is actually
processed, dom(W1) will be true and W1 will be (correctly) omitted from the
view.