Non-numeric input when numeric input is expected causes error, not rejection

[cemerick]

> (a/advance (a/compile [(int \f)]) nil \f ::fail)
ClassCastException java.lang.Character cannot be cast to java.lang.Number  automat.stream/to-stream/reify--91907 (stream.cljc:73)

to-stream's prior attempt to cover the narrow case of char input when expecting a number caused other issues (#34), but the char/int mismatch is just the most obvious/convenient/common case. Any FSM that requires a numeric input to advance, but encounters one that can't be coerced to a number will fail with a ClassCast instead of rejecting.

A straightforward way to address this would be to signal rejection in the reified nextNumericInput impl if the return isn't actually a number. That would cover the immediate problem.

One interesting/useful case that this wouldn't cover is where one has an FSM expecting a numeric input, it encounters something non-numeric, but you'd like to account for this via the :signal mechanism. Right now, that's not possible at all, but in such a case, it could "back off" to use nextInput, get the non-numeric result, apply the :signal fn, and then attempt to continue. This might belong in a separate enhancement issue, but I think it would nicely shave off a rough corner and make :signal much more general-purpose. At the moment, I'm "preprocessing" inputs to my FSM because some never get to :signal in the first place.