Consolidate lambdas and method references in Collectors.java emul

[niloc132]

Each lamdba or method reference results in a new "anonymous inner class" in GWT output. This patch deduplicates many of those to avoid multiple classes for a single purpose.

The joining() overloads have specific inner classes rather than multiple (two and four respectively) method references.

Partial #10207

[niloc132]

Testing methodology: Ran test.web.htmlunit with -setProperty compiler.useSourceMaps=true on the following suite:

package com.google.gwt.emultest.java17;

import org.junit.runner.RunWith;
import org.junit.runners.Suite;

@RunWith(Suite.class)
@Suite.SuiteClasses({
  com.google.gwt.emultest.java8.util.stream.CollectorsTest.class,
  com.google.gwt.emultest.java9.util.stream.CollectorsTest.class,
  com.google.gwt.emultest.java10.util.stream.CollectorsTest.class,
  com.google.gwt.emultest.java17.util.stream.CollectorsTest.class,
})
public class CollectorsSuite {
}

Enabling sourcemaps has the effect of disabling emulated stack trace mode for tests, which gives a more accurate picture of the size of the output. Running all existing CollectorsTest impls ensures that each method is called.

cd user/
ant test.web.htmlunit '-Dgwt.junit.testcase.includes=**/CollectorsSuite.class' '-Dtest.args=-ea -sourceLevel auto -setProperty compiler.useSourceMaps=true'
ls -al ../build/out/user/test/web-htmlunit/www/com.google.gwt.emultest.EmulSuite.JUnit/*.cache.js

Before:

-rw-r--r-- 1 colin colin 153339 Jan  3 15:32 ../build/out/user/test/web-htmlunit/www/com.google.gwt.emultest.EmulSuite.JUnit/268B54448E4841FC4907C8EF0CF3E320.cache.js

After:

-rw-r--r-- 1 colin colin 151753 Jan  3 15:26 ../build/out/user/test/web-htmlunit/www/com.google.gwt.emultest.EmulSuite.JUnit/24245B1CC63870803F03BF290787ECB3.cache.js

Savings of 1586 bytes.

[zbynek]

Looks good, though some parts may be redundant if #10160 gets implemented.

[niloc132]

Yeah I don't have super high hopes for #10160 - just keeping it focused on array creation and IntFunction at least narrows it a lot, but when you start to look at method references in general and all the various functional interfaces that could exist... plus how this might interact with incremental compilation, it has me a little worried.

Maybe there could be a giant Interface+methodref lookup that dedups during optimization, but the method reference info itself is gone by then (GwtAstBuilder sees the actual method ref from JDT, but then creates plain classes out of it), so we'd have to add other metadata or redo parts of the gwt ast. Definitely not saying it can't be done (and it would be a great idea, should have more benefits beyond this), would definitely take a lot more work to get to this first 1.5kb than just manually deduping the method calls.