Add support for stubs to declare intersection type class properties

[Girgias]

Haven't figured out yet how to do return types and function parameter types, but this is a start.

[kocsismate]

I noticed that proper intersection type support is still needed in the below methods:

• Type::fromString()
• Type::toOptimizerTypeMask() and Type::toOptimizerTypeMaskForArrayValue()
• Type::getTypeForDoc() (+ phd support should also be added)
• Type::equals()
• Type::toString()

[Girgias]

I noticed that proper intersection type support is still needed in the below methods:

* `Type::fromString()`

Done

* `Type::toOptimizerTypeMask()` and `Type::toOptimizerTypeMaskForArrayValue()`

Maybe I'm wrong, but this seems unapplicable because intersection types can't have scalars types?

* `Type::getTypeForDoc()` (+ phd support should also be added)

PhD support has been added a while ago: php/phd@094794e

* `Type::equals()`

I'm not sure any changes need to be made to that as the logic looks sound to me for both cases

* `Type::toString()`

Done

[kocsismate]

Do you think it's worthwhile to also add a function with intersection param and return types?

[Girgias]

I'm not sure how to do the check with ZPP or is it possible to them manually?

[kocsismate]

Yeah, I think you should rely on manual param parsing for now, but we could add a ZPP when we will have a real use-case for an internal intersection param type.

[kocsismate]

Maybe I'm wrong, but this seems unapplicable because intersection types can't have scalars types?

Even though optimizer type masks support the object type, you are right in the sense that we cannot really specify the type mask further now.

The only small issue I can imagine with the current implementation (and probably it's an existing problem) is that MAY_BE_OBJECT is added multiple times to the type mask if the type includes multiple classes.

[Girgias]

Maybe I'm wrong, but this seems unapplicable because intersection types can't have scalars types?

Even though optimizer type masks support the object type, you are right in the sense that we cannot really specify the type mask further now.

The only small issue I can imagine with the current implementation (and probably it's an existing problem) is that MAY_BE_OBJECT is added multiple times to the type mask if the type includes multiple classes.

Isn't it a bitmask? So adding it multiple times shouldn't change anything other than being somewhat redundant?

[kocsismate]

Isn't it a bitmask? So adding it multiple times shouldn't change anything other than being somewhat redundant?

Yes, I was only referring to the redundancy. :)