feat(type): Notnull type optimizations

[veewee]

Fixes #357

There is still one situation, where you use nonnull() inside a shape().
In this situation, the type will resolve to mixed (inluding null).
This can only be solved once psalm has a TNonNull type.

Thanks @devnix !

[coveralls]

Pull Request Test Coverage Report for Build 8613784700

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 98.781%

---

Totals
Change from base Build 8581981192:	0.0%
Covered Lines:	4377
Relevant Lines:	4431

---

💛 - Coveralls

[azjezz]

I don't like that we are exposing an internal type, but i think its okay in this case.

another option is to introduce a new interface as part of the public API, like EliminiationTypeInterface and have nonnull return EliminiationTypeInterface<null> .

example:

interface EliminiationTypeInterface<TEliminated, TGroup> extends TypeInterface<TGroup>
{
    public function matches<TInput: mixed>(
        TInput|TEliminated $value
    ): ($value is TEliminated ? false : true);

    public function coerce<TInput: mixed>(
        TInput|TEliminated $value,
    ): ($value is TEliminated ? never : TGroup);

    public function assert<TInput: mixed>(
        TInput|TEliminated $value,
    ): ($value is TGroup ? ($value is TEliminated ? never : TGroup) : never);
}

[veewee]

@azjezz That could work - but the interface would be broken by design:

extends TypeInterface<TGroup>

Since there is no way in psalm for doing an Exclude, it will always tell the upstream that it is of type TGroup - yet it is of type Exclude<TGroup, TEliminated>.

Not sure if that is a better solution than leaking one internal that most likely wouldn't affect much applications.
I could make a comment on the "why we did this" there ?