At least 2 defects in javalib Collectors#joiner method

[LeeTibbert]

Whilst studying the ripples of PR #3396, I discovered two defects in the javalib Colectors#joining method(s).

• The first is user visible, albeit hard to provoke: the combiner.apply(arg1, arg2) function fail the deliminator
  with which the collector was created between arg1 & arg2.
  (For the detail oriented, the collector can not be created with a null deliminator, but it can be created with
  an empty string as the deliminator. It is hard to distinguish the cases of the empty string not being added
  and it having been properly added. Other deliminators are clearly visible to the determined.)

  Imagine the case of Collectors.joining("|"). A currently private test gives the expected results on JVM but
  fails on Scala Native:

Test org.scalanative.testsuite.javalib.util.stream.CollectorsTest.collectorsJoining_MergeSN failed: 
org.junit.ComparisonFailure: unexpected combined expected:<Left[|]Right> but was:<Left[]Right>

• The second defect is visible to people wanting to use the Collector.joining#merge method. Normally, this
  would be either nobody or library writers.

  Reverse engineering (but not looking at the JDK code) shows that JVM
  uses a StringJoiner for the accumulator A method in [T, A, R]. Scala Native uses a StringBuilder.
  To be fair (& defensive), StringJoiner was not available when that code was written.

  Normally the A methods is abstract and "do not care". In the admittedly abstruse Test mentioned above, the
  difference means that the same Test can not be compiled & run on both JVM and Scala Native.

  Those writing implementations of parallel stream methods, say a parallel collect() are likely to use the
  combiner method and encounter difficulties.

[LeeTibbert]

Normally the A methods is abstract and "do not care". In the admittedly abstruse Test mentioned above, the
difference means that the same Test can not be compiled & run on both JVM and Scala Native.

Later: I re-wrote the test so that it can execute without knowing the accumulator implementation type.
The introduces the restriction that both arguments are allocated by the exact same Supplier.
(which gets the unseen internal type A the same). This means that the prefix, suffix, & deliminator
for both arguments must be the same. OK in a test, but perhaps problematical in the World.

          In my trial Collectors.joining() code, I changed the implementation type to `StringJoiner` to match
          the JVM.  Now that the type A has been reverse engineered and `StringJoiner` (will soon) exist(s),
          no real sense to SN differing.

[LeeTibbert]

A fix for this issue is ready a day or two after StringJoiner becomes available.