This changes representation inference to be bidirectional:
1. truncations are propagated from uses to definitions.
2. output types are propagated from definitions to uses.
(and nodes are revisited until fixpoint.)

At the moment, (2) is used only superficially; the idea here is to
use the output type propagation to propagate types from type feedback.

For the output types to be usable, we need to keep track of the type
of the JavaScript value rather than the truncated value. Otherwise,
representation inference could not rely on the ranges indicated
by the values.

For example, for "var b = (a|0) + (a|0); return (b/16) >>> 0",
the type of b cannot be int32; otherwise the division "b/16"
would believe that it is fine to do an integer division on
the truncated value, which would give a wrong result for
2^31 <= a < 2^32.

The change makes representation inference a bit more expensive
(the phase is about 20% slower), but since this is only small part
of the overall compiler time, the overall effect is negligible.
If the running time becomes a problem, we could optimize this by
remembering when the nodes are stable (ie., no further changes to
type/truncations) and/or explicit subscriptions for changes.

BUG=v8:4583
R=bmeurer@chromium.org
LOG=N

Review URL: https://codereview.chromium.org/1490763003

Cr-Commit-Position: refs/heads/master@{#33112}