Fix incremental compile warnings in dynatablerf sample.

Change-Id: I8eaa66d066e289de997335ccea7330667e23c303
Add NavigableSet, NavigableMap to GWT.

This change also:
- Adds missing null checks to collections to fix tests.
- Makes entry value comparison null-safe.
- Uses internal removeEntry method in EntrySet iterators,
EntrySets, pollFirstEntry and pollLastEntry methods for
compatibility with OpenJDK.

Tests adapted from Apache Harmony.

Authors: Andrei Korzhevskii, Louis Wasserman
Bug: issue 4236
Change-Id: I2800b2b54b06a7ef255e01ad44b11909d878362a
Add missing return in JavaScriptObject#toStringVerbose.

Bug: issue 8948
Change-Id: I0d31bc6980da57672a0c63fa40a05a39d352d9b7
Makes Throwable to keep the backing js error.

Earlier I did some refactorings towards making GWT exceptions
look like real Javascript Errors. One of them was to make
StackTraceCreator behave like Chrome's Error.captureStackTrace
so that it will store a stack property to the passed object.
I was going to follow up with changing Throwable's prototype
to Error.prototype so that it would be a real javascript error.

This is working good if you just print the stack to the console
however this is not much helpful for debugging as the printed
stacks is not clickable (Only Chrome prints clickable links but
it doesn't do that when a sourceUrl is provided and we need to
do that for superdev).

An alternative is logging the exception by re-throwing it via
timeout and let the console handle it. Even though this works
on Chrome (only when console is already open), it doesn't work
with custom error objects.

As the custom Error object concept still too futuristic for
today's browsers this patch goes back to more traditinal approach
by leting java Exception carry its backing javascript error with.
This is relativly simpler in implementation and gives ability for
loggers to print clickable stack by re-throwing the backing
exception or can let a compiler pass to unwrap it when thrown
like we do for JavaScriptException.

Change-Id: I43bc1c2b2deb74d863cfd8c59b281286f600c709
Re-introduce outputDirectory custom conf in Maven-based samples.

Change-Id: Idc43b626e67de86559548b4fdae97481907e9ca3
Restores Java 6 compatibility for JavaScriptException.

Change-Id: Ia36d16bd0ab613c9afe7b3f35359a5e14243df2a
Fix IOOB in StyleInjector in IE10 when doc contains more than 30 sheets

IE10 removes [1] (or significantly raises [2]) the limits on the number
of style sheets that a document can contain, but StyleInjectorImplIE
expected that no more than MAX_STYLE_SHEETS could exists, and used the
actual number of stylesheets as an upperbound in a loop over an array.
This causes an IOOB in IE10 when the limit is exceeded.

This change therefore:
 * fixes the potential IOOB by using the array length as the upperbound
 * uses the StyleInjectorImpl in IE10 instead of StyleInjectorImplIE
 * updates MAX_STYLE_SHEET to 31 (from 30) as it's the actual limit in
   previous versions of IE.

[1] http://msdn.microsoft.com/en-US/library/ie/hh920762.aspx
[2] http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/internet-explorer-stylesheet-rule-selector-import-sheet-limit-maximum.aspx

Bug: issue 8863
Change-Id: Id96bb5835022501548b6f24514d0a5ff1a27141d