"char": implement "is_whitespace" and "maybe_digit" using "std::unicode::icu"

[kud1ing]

"is_whitespace" and "maybe_digit" should be implemented using the libicu binding in module "std::unicode::icu".
libicu is battle tested, we should not replicate their effort.

See #1370

[boggle]

Both these tickets require that unicode.rs (and linking against libicu) is moved to core (which we try to keep small). Then again, the contents of libcore is not final yet (c_vec, dbg coming to mind).

[kud1ing]

I sympathize with this goal.

Currently we pretend to do unicode in libcore, but it's really only the ASCII-subset.
Maybe we should organize it like this:

• libcore:
  • std::ascii
• libstd:
  • std::unicode
  • std::char (decides wether to use std::ascii or std::unicode)
  • std::str (decides wether to use std::ascii or std::unicode)

D performes similar decisions in their std.string: https://github.com/D-Programming-Language/phobos/blob/master/std/string.d

The downside is a duplication of functions/interfaces.

[boggle]

If one wants to do ASCII, one can always use [u8]. Arguably vecs need better support in core (sub"string" functions and the like). char is defined to be a unicode char. core is - to my understanding - loosely defined to hold all that is absolutely necessary to make sensible use of built in primitives. So char and unicode should move to core, I guess.

[kud1ing]

I think the type "str" is not defined in module "str". Is it a bultin-in?
I am not sure, we need "char" and "str" in libcore at all.

[boggle]

I think they are both built in and thus support code for them should go to libcore. Maybe graydon can decide this?

[kud1ing]

Sorry, i meant: I am not sure, we need the modules "char" and "str" in libcore at all.

[kud1ing]

"is_whitespace" is implemented in ac13f0d according to the script-proposal in #1348