fromSb3: Auto-coercing "number/text" procedure inputs into numbers loses data

[towerofnix]

I haven't tested but it seems that a procedure input which gets passed onto random might, for example, lose the decimal suffix in 123.0 with obvious semantic value — as well as more subtle string-vs-number cases in Scratch.

As complete compatibility with Scratch hadn't been a major concern, this wasn't a major issue, but now that we're narrowing in and recently did a lot of work on type-casting compatibility, we should ensure this is compatible.

It's OK to always serialize the input as a string, which is a quick fix, but we can do better with static analysis: if the argument is only ever passed to block inputs which take numbers and not any other types, it's safe to coerce the input into a number. (See #93, foundational to this kind of analysis.)

This is possibly a separate issue, but we may want to reinspect how the type of procedure arguments is interpreted: if a procedure input is only ever provided with number-returning blocks (or coerced numbers), we can treat the return type of the argument block as number, but otherwise we have to convert it from string (when non-strings are desired).

[towerofnix]

This came up again in #9: we can't serialize "set my number to 0x16" as this.vars.myNumber = 0x16 because the variable might be treated as a string later on, in which case the 0x16 detail is important. (Yes, this goes for decimal numbers too, as noted above: "123.0" != "123". We're just ignoring that for now, which is the wrong thing to do in a perfect world.)

We need to perform the exact same kind of static analysis as discussed above for custom block inputs, only across the scope of the project (or sprite): is the variable ever used in any string-handling blocks?

But it's not trivial to test this. We also need to be aware of how the value of a variable (or custom block input!) can bubble out: "set var2 to (var1)", "set my fruit count to (input: # of fruits)". If those values are ever treated as a string, then we need to consider "var1" or "# of fruits" as also being number-unsafe (and so provide them string values, every time).