Relax flow typing checks on Flexible Types

[HarrisL2]

These changes allow flow-typing to view flexible types as non-nullable at relevant places.

//> using options -Yexplicit-nulls

def main() =
  var result: String | Null = null
  result = "".trim()
  result.trim()

Without this PR, the access of trim on result will give an error. This pattern is used in community build projects like sconfig.

After this change, calling .nn on a flexible type directly will still not give a warning, as intended.
However, calling .nn on a variable that is previously flow typed to be a flexible type will now give a warning as a side effect of this change. We believe that the benefits of this change outweigh the drawback.

[noti0na1]

I don't agree reporting warnings for .nn on flexible types, since it correctly rules out implicit nulls.

I would also not make flexible type a "notnull" type. It can have null value by definition...

[olhotak]

isNotNull is used in a number of places. One of those places is flow typing. @HarrisL2 you had some specific compelling use cases from the community build that would bring a significant benefit to flow typing from this change. Can you put some of those examples (or modified illustrative examples) here in the discussion and/or as compiler tests on this PR?

It may be that flow typing should use a different version of isNotNull than some of the other places where the compiler calls isNotNull. It would be useful for us to discuss the motivating examples for flow typing.

[HarrisL2]

I could not find the example where the change for isNotNull is needed. But I did find an example for the change in NullOpsDecorator.scala:50.

//> using options -Yexplicit-nulls

import java.math.BigInteger
def main() =
  val bint: BigInteger = new BigInteger( "5")
  var result: BigInteger | Null = null 
  result = bint.multiply(bint)
  result.longValue

gives an error for accessing longValue.

Having the change allows the access, but gives a warning if we use .nn.

I don't agree reporting warnings for .nn on flexible types, since it correctly rules out implicit nulls.

I would also not make flexible type a "notnull" type. It can have null value by definition...

If so, we could make it so that we don't give warnings if the .nn is on a FlexibleType.