Add string.trimLeft/trimRight.

tests/corelib/corelib.status

Index: tests/corelib/corelib.status
diff --git a/tests/corelib/corelib.status b/tests/corelib/corelib.status
index edba2765089348761622df8f86f6acea26d9217f..3c56c5cbff18294b9961e353170d23aacd65ae7f 100644
--- a/tests/corelib/corelib.status
+++ b/tests/corelib/corelib.status
@@ -111,6 +111,9 @@ list_as_map_test: Pass, Slow # TODO(kasperl): Please triage.
 
 [ $compiler == dart2js && ($runtime == firefox || $runtime == safari || $runtime == chrome || $runtime == drt) ]
 
+[ $compiler == dart2js && ($runtime == d8 || $runtime == chrome || $runtime == drt || $runtime == safari) ]
+string_trimlr_test/none: Fail # Bug in v8. Fixed in v8 r19222, 2014-02-10.

[floitsch, 2014/03/12 12:34:29]

If it was just a v8 bug we could ignore it and wait for the fix to reach stable.
Since it is also present in safari we should change our library function to work
with it.

[Lasse Reichstein Nielsen, 2014/03/12 14:54:50]

The change would be not using the JS trim function, which would likely cost in
performance. It's not a new issue with this change, it was just not tested
before, but the existing trim function has the same problem.

I think it's a rare occurrence to actually trim U+200B, and therefore not likely
to be a problem in practice (although it is rather annoying). We generate code
that is valid for ES5, it's just that Safari (and V8 for a little while yet) are
not ES5 compliant.

V8 changing behavior could be the thing that makes JSC look at it again. I'd say
we keep it as-is for now, and see if it causes any problems.

+
 [ $compiler == dart2dart ]
 compare_to2_test: Fail # inherited from VM
 unicode_test: Fail # inherited from VM