Refactor string utils for better consistency

[MaxGraey]

Moving parseFloat/parseInt/parseI32/64 from std/string to std/util/string

[dcodeIO]

Hmm, initial idea here was that the parseXY functions are actually global (JS) APIs and not really utility, so live in the top level file, while the underlying implementations live in util. Not sure.

[MaxGraey]

In current PR I'm proposing put this in utils and reexport to std/string. My thoughts are better all implementations be in one place instead parse<T> in util/string, rest in std/string.

[dcodeIO]

So, the problem seems to be that the implementation of `parseFloat´ is at top-level, while the implementations for integers are in util, I guess? What if we keep the integers, and refactor just parseFloat (maybe becoming generic) to use a similar design?

[MaxGraey]

Or better move parseInt/parseFloat to buildins.ts. And remove parseI32/parseI64 because we have I32.parseInt/I64.paseInt. WDYT?

[dcodeIO]

Aren't really builtins, but one could argue that isNaN and similar should be moved to number. Removing parseI32/I64 sounds good!

[MaxGraey]

I also renamed internal parseFloat to strtod

[dcodeIO]

Looks like it will conflict if we ever align the resolver with JS to also take the current function's name into account.

[MaxGraey]

What if I declare it as function internal_isNaN without export and in the end of file export as:

export { internal_isNaN as isNaN, internal_isFinite as isFinite }

?

[dcodeIO]

Same. Not sure how TS handles this if general signatures differ, like one being generic and the other not.