Add support for Unicode codepoints

[smarr]

These changes introduce support for converting characters, i.e., elements in a string into their Integer representation in terms of Unicode codepoints. It also introduces support for creating characters from Integers representing codepoints.

Overview:

• convert an array of characters to a String
• convert an integer into a character
• convert a one-element String into a 16-bit code point
• signal ArgumentError, i.e., violations expectations on method argument
• fix parsing issues with unicode character literals (couldn't parse multi-part characters)
• document design of Exceptions vs Errors

@daumayr, you didn't say anything with respect to the ArgumentError naming question.
Which system should we use as general style guide, Java, Dart, something else?
ArgumentError is not in Newspeak.

TODOs

• figure out whether it is sufficient to return char when converting length-1 Strings to number. How to deal with characters that are 2x 16-bit, i.e., how to support the full unicode code point range?
  • The solution is to use full Integer for this, and don't mess around with it on the SOMns level
• add tests for all methods, and exercise some unicode characters, emojis, etc.
• add helper for signaling exception with receiver class
• document style and naming preference in /docs/
• add comment on Errors vs. Exceptions to Kernel
• fix issue about character literals and emojis not parsing correctly.

[smarr]

@daumayr hmmm, is there a good reason why we have a Character class? It currently doesn't do anything beside providing factory methods. Might those belong into String?

[smarr]

@daumayr can we debate the current design, and restrictions?

I think, it would be less restrictive if String>>#from: would be String>>#fromStringArray: and then accept strings of any length in the array.

[smarr]

I would argue we want to have something similar to this:

class  String = ()() : (
  public fromStringArray: arr = (
    ^ arr inject: '' into: [:a :b | a + b ]
  )
)

Possibly with a check that b is really a string though, because we don't want implicit conversions.

[daumayr]

@smarr ArgumentError is from Dart, I don't have a strong preference. Generally Errors should not be caught by programs. In Java there is IllegalArgumentException, so whether we wan't users to catch it plays a role in the final decision.

String>>#fromStringArray: sounds reasonable

The methods from Character could be moved to String.
Maybe String>>#charValueAt: and a static #fromCharValue: ?

[smarr]

Ok good, I should document the Dart preference as part of a style guide in the docs, I think.

And, I probably need to document that character literals don't support long unicode code points (like for emojis).

[smarr]

@daumayr could you have a look at this again and see whether it satisfies all your requirements?

@Richard-Roberts might be interesting to you. We now got more robust unicode support.

[daumayr]

looks good