Replace stringN type names with String<N>

[sbillig]

What is wrong?

The parser will parse string<100> etc as a TypeDesc::Generic, so it's time to retire the old string100 syntax in favor of the const generic style. We should also do bytes<N>, if we're keeping the bytes type. (See #258)

How can it be fixed

[cburgdorf]

Yeah, would be nice to retire the string100 syntax, the (limited, builtin) const generic style of string<100> would be a nice thing to show off on the website 😍 when it launches soon 🙃

[g-r-a-n-t]

Lets make this String<N> instead of string<N>.

[sbillig]

The complicated part of this is that the generic syntax will have to be allowed in a type constructor call, eg x = String<10>("hello"), which adds ambiguity to expression parsing. String<10>("hello") will currently be parsed as (String < 10) > "hello". We'll run into the same issue if/when generic functions are supported, assuming the type parameters can be specified explicitly. f<T>(10) or (f<map<u8, foo>>(x)) (is it a tuple or a generic fn call?)

This ambiguity is the reason for rust's "turbofish" syntax. However, I think we should take the approach outlined in this RFC: https://github.com/varkor/rfcs/blob/undisambiguated_generics/text/0000-undisambiguated-generics.md Basically, just resolve the ambiguity in favor of generics (and probably disallow chained comparisons while we're at it). This will add complexity to the parser, but I think that's better than adding the ugliness of the turbofish to the language.

Here's a summary of the crazy discussion thread that the rfc spawned: rust-lang/rfcs#2544 (comment)

Note that I haven't entirely read either of those links, but I think the general sentiment among the rust lang team was to accept the rfc (before the conversation derailed and was closed), and my inclination is to follow their lead.