Introduce FFI::Scope class

[dstogov]

This is a refactoring of user level ext/FFI API.
The most important changes are in ffi.stub.php.

Now FFI::cdef, FFI::load and FFI::scope return an instance of new FFI\Scope class instead of FFI.

There is no way to instantiate an object of class FFI. Methods FFI::new, FFI:cast, FFI::type may be called only statically. The deprecation introduced by 4acf008 is removed. (I can't find the RFC corresponding to this deprecation).

FFI\Scope::new, FFI\Scope::cast, FFI\Scope::type can't be called as static methods.

Most tests are not affected by this change, but of course this patch may break some user code.

[nielsdos]

@dstogov This is the RFC that made the static methods deprecated: https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#fficast_ffinew_and_ffitype this happened in 8.3. It was part of a larger RFC.
This PR is a draft, so I suppose this isn't ready yet for review, and GitHub is just confusing me by saying it already did a request for review?

[dstogov]

@nielsdos Thanks for pointing to the RFC.

The implementation should be good enough, but this PR requires RFC and I don't like to post it now.
It would be great to hear your initial opinion.

[nielsdos]

I think, this path forward makes sense.

[nielsdos]

Often, @strict-properties is added to final non-serializable classes alike these. But no strong preference.

[arnaud-lb]

I understand that the goal is to address https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#fficast_ffinew_and_ffitype in an alternative way?

This makes sense, and there are almost no BC breaks, except in at least these two cases:

• Code with FFI type hints. Such code can be made compatible with <8.3..master by typing FFI|FFI\Scope (However static analyzers may not be happy about calls to ->new() on a variable of type FFI|FFI\Scope if the method does not exist in both classes. This could be annoying but not really a BC break.)
• Code calling static methods with the syntax $instance::method() may break, as FFI\Scope does not have the static methods. We could mitigate this by adding the static methods to FFI\Scope.

One issue that is not solved is that the methods new, type, and cast collide with C function calls. All instance calls on FFI\Scope forward to C, except those, so it is not be possible to call C functions with these names. Also, adding new methods on Scope in the future would be a BC break. Maybe we could deprecated these methods on FFI\Scope?

[dstogov]

I understand that the goal is to address https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#fficast_ffinew_and_ffitype in an alternative way?

Yes. This is an API re-factoring to avoid static/non-static mess.

* Code calling static methods with the syntax `$instance::method()` may break, as `FFI\Scope` does not have the static methods. We could mitigate this by adding the static methods to `FFI\Scope`.

There is no sense in static methods, because they can't reach symbols loaded into the instance of the Scope.

One issue that is not solved is that the methods new, type, and cast collide with C function calls. All instance calls on FFI\Scope forward to C, except those, so it is not be possible to call C functions with these names. Also, adding new methods on Scope in the future would be a BC break. Maybe we could deprecated these methods on FFI\Scope?

These non-static methods are necessary (now static methods are deprecated).
I don't see a big problem in reserving new, type, cast and prefer to keep API compatibility.
There are no plans to add new Scope methods.