The idea is that some unions usually make more sense than others. For instance,
if `Apply` and `Ident` are case classes that extend `Tree`, it makes sense to
widen `Apply | Ident` to `Tree`. But it makes less sense to widen `String | Int`
to `Matchable`.

Making sense means: (1) Matches our intuitive understanding, and (2) choosing not to
widen would usually not cause errors.

To explain (2): In the `Tree` case it might well be that we define an implicits on `Inv[Tree]` for
invariant class `Inv`, and then we would not find the implicit for `Inv[Apply | Ident]`.
But it's much less likely that we are looking for an implicit of type `Inv[Any]`.

This commit does two things:

 - add logic not to widen a union if the result is a product of only transparent traits or classes.
 - treat `Any`, `AnyVal`, `Object`, and `Matchable` as transparent.

 - include js.Any and js.Object
 - include others ...Ops and Is... classes from collections
 - Change the implementation so that we don't have to load
   traits or classes that are assumed transparent.

They give test failures, and I don't know enough about the js class hierarchy to
be able to fix them with confidence.

 - Introduce hard and soft unions
 - Explain how transparency of base traits influences type inference
 - Drop outdated note on possible future changes

Co-authored-by: Guillaume Martres <[email protected]>