Unify the parsing of all class-like member declarations

[TysonAndre]

Using a class-like member in the wrong class-like is a compile-time error, not a parsing error. Tolerate it and parse the current/remaining statements and leave it to the applications to warn about using unexpected members in classes, traits, interfaces, or enums. (Or to tolerate them for stubs for editors/IDEs)

Related to #395

https://github.com/php/php-src/blob/PHP-8.3.1/Zend/zend_language_parser.y#L622-L638

https://github.com/php/php-langspec/blob/master/spec/15-interfaces.md exists but doesn't mention AST nodes that would become compilation errors

[TysonAndre]

I have mixed feelings about this. It's similar to what https://github.com/nikic/php-ast does (php's internal representation of its ast) but for many applications it'd add work in reintroducing the check of allowed class-like member types or adding new logic for class-like member types.

I'd expect a small benefit in doing a better job of parsing the remaining class-like members in some cases or in being able to stub interfaces such as UnitEnum/BackedEnum that have properties https://wiki.php.net/rfc/enumerations#new_interfaces .

[roblourens]

This approach seems straightforward and makes sense to me- do you think we should do this or try to do a better job of parsing class-like members?