+str #15736 EARLY WIP on Source/Sink/Flow JavaAPIs

(expected to not compile on jenkins): Not all tests compile yet (need to update to new style, but first need to rebase onto `runWith`). the javadsl itself compiles.

This is an **very early WIP**, many things have not been addressed yet, such as:

* FlowGraph
* tests don't compile 
* documentation

The general design is keeping the DSLs completely separate (didn't fully get to MaterializedMap yet), and there are `asScala` / `asJava` converters available. They're available on the Java "impls" as well as as `StreamConverters._` (ala' the collections converters).

Changes needed from akka-actor: We'd need to make `japi` variant (all Function etc in there are currently invariant, which doesn't play nicely with the variant stream apis). Currently it's put in a `japi` object in streams, as streams depends on a released akka version.

The reason we need to duplicate delegation is because of return types (lack of higher kinds, like the scaladsl does)... Not sure if this can be made more DRY without complicating too much.

Some operations that are now deleted might have leaked, will now rebase and delete them in case there are some leftovers (need to rebase onto `runWith` now).

I have used `javadsl.Xxx` to 1) lessen my confusion when converting migrating types 2) make reviewing easier. There shouldn't be any scaladsl leaking in these parts I hope.

I'll point out a few lines I'd like to discuss via comments.
This does not work as well for Java as it does for Scala, I’d propose to invert it: the TapWithKey knows which type it extracts from a given MaterializedMap, no inference necessary.
~~~java
final MaterializedMap map = ...;
final Future<Something> f = futureSink.valueIn(map);
~~~