Fix return type checking to allow aliasing for non-ephemeral return types.

[jemc]

This PR fixes return type checking to allow aliasing for non-ephemeral return types.

I discovered this type system issue after a discussion with @rkallos in which we discussed how to fix Map.insert (and others) to not have an unreachable error case.

Looking into it further, I discovered that the type system had a simple bug that wasn't obvious due to the inconsistency in how Pony handles return type checking (the fact that using the ephemeral modifier is required to describe a unique return type, whereas on all other type specifications, the ephemeral modifier is useless).

This PR doesn't address that inconsistency, because it would be a major breaking change for the language, but this does fix the small bug that went unnoticed because of it.

The bug can be reproduced with the following code, in which get_1 and get_2 are valid and functionally identical, but the latter fails to compile:

class iso Inner
  new iso create() => None

class Container[A: Inner #any]
  var inner: A
  new create(inner': A) => inner = consume inner'
  fun get_1(): this->A => inner                        // works
  fun get_2(): this->A => let tmp = inner; consume tmp // fails

actor Main
  new create(env: Env) =>
    let o = Container[Inner iso](Inner)
    let i_1 : Inner tag = o.get_1()
    let i_2 : Inner tag = o.get_2()

Upon investigation, it turned out to be a simple boolean logic bug, in which not (A or B) was expressed as !a || !b instead of the correct !a && !b. The code comment several lines above the change expresses the intended meaning, so I know that this fixed logic reflects the code author's original intent.

[SeanTAllen]

Wow. Heck of a find.

[jemc]

For posterity, I'll note that @SeanTAllen asked me in Zulip to elaborate on the "inconsistency" I mentioned above. You can find that conversation here: https://ponylang.zulipchat.com/#narrow/stream/189952-compiler-discussion/topic/return.20type.20ephemeral.20notation.20inconsistency

[jemc]

The CI failure appears to be unrelated?

[SeanTAllen]

@jemc yeah, i think so, it's been flakey lately.

[jemc]

Okay, was going to kick off another CI build, but that'll take forever to finish - I'm just going to merge.

[jemc]

But first, a changelog entry was added.

[SeanTAllen]

Looks like the job was straight up cancelled. Eventually cancelled jobs will get rerun. Or should. But I've been seeing them not get rerun lately. Such is life with free stuff I guess.