Deprecate many ArrayIterator methods that are aliases to ArrayObject ones

[morrisonlevi]

This will need an RFC, I think.

These are needless, and cause problems (see some of the bugs lol).
Generally if you want these methods, use an ArrayObject directly.

I intend to remove these and possibly more in PHP 9.0 so that
ArrayIterator can be made efficient.

Of the deprecations included, the only ones I'm not sure about are
the serialize/unserialize ones with the Serializable interface. We
want those to go away eventually, but not sure if we're ready to
add a deprecation notice on this particular usage.

[kamil-tekiela]

I'd prefer to just switch off E-DEPRECATED in ini settings instead of using error_reporting(0). Is there a problem in fixing the test cases to avoid the deprecation warning or just silencing E_DEPRECATED?

[morrisonlevi]

Ignoring E_DEPRECATED is fine with me.

[morrisonlevi]

I'm going to clean this up and prepare it for discussion.

@nikic, since you are the one who probably knows the most about
serialize/unserialize and what's best practice, what is your opinion on
the @deprecated for serialize/unserialize methods on ArrayIterator?
Too early, wrong, or go ahead?

[ralflang]

I think it should be similar to what happens with the Serializable interface by itself:
If you only have

implements Serializable
public function serialize(): ?string
public function unserialize(string $data): void

then issue a notice DEPRECATED.

If you add

public function __serialize(): array
public function __unserialize(array $data): void

then you issue no notice DEPRECATED even if the Serializable interface is present.
I see no need to hurry this transition.

[Girgias]

@morrisonlevi do you want to rebase this or not?

[Girgias]

Handled in #23074