Add native return types where possible

[Seldaek]

Thanks to @dseguy using some of his https://www.exakat.io/ tech I got a list of ~100 classes/interfaces which are extended by the ~2500 packages requiring composer/composer. This allowed me to avoid touching public/protected methods for these, to hopefully mostly avoid breakage in third party packages due to the added return types.

Other files as well as tests have had all their return types added.

The other potential problem point is in 84f0f19 which splits some of Composer\Composer into a base class Composer\PartialComposer for global instances which are not fully loaded for perf reasons. This allows the code here to remain simpler with less nullable properties/getters, but it may have some impact tho that's harder to predict.

The goal here anyway is to ship this out and then promptly undo any return type which causes too much unintended pain. It's the best compromise I've found between doing nothing and doing a hard break for 3.0 forcing all plugins to be updated again.

[mroforolhc]

In this pre-release writted that:

Added return types where possible. This will break code that extends ours and does not declare the same return types. For this reason, our most extended classes/interfaces have not been modified to retain BC: Composer\IO*, Composer\Installer*, Composer\Autoload\ClassLoader, Composer\InstalledVersions, Composer\Plugin*, Composer\Repository*, Composer\Util{Filesystem,HttpDownloader,RemoteFilesystem} and a few select others.

but this pull request contains changes in Composer\IO\*. help me to understand, please.

[stof]

Well, NullIO was not considered as being part of the most extended classes