Bump minimal PHP version of GetID3 2.x to PHP 7.2

[StudioMaX]

I have wanted to propose this for a long time, but I'm not sure how we should better implement this on GetID3 2.x.
Despite the fact that getid3.org indicates that GetID3 2.0 needs PHP 7.0.0 and highter, in fact, GetID3 2.0 currently requires PHP 5.4 and higher. This is indicated in the composer.json and in the CI workflow. And in fact, the codebase is indeed compatible with PHP 5.4.

For GetID3 2.0, I think this is redundant and we can switch to PHP 7.2 as the minimum supported version. PHP 7.2 is also EOL, but is still very popular.

But there is a problem here, since in fact version 2.0 was never released and was always in the dev-branch (I'm not talking about the old getID3 2.0 that were distributed many years ago through sourceforge/forum, but only about 2.x that in modern world is distributed via Composer/Packagist). We only made a few alphas as releases of 2.0.
Due to the fact that many require james-heinrich/getid3:^2.0-dev in their composer.json, we cannot safely change the current minimum version of PHP from 5.4 to 7.2, as this will break backward compatibility.

Therefore, I suggest to release the latest alpha (or even a RC) of branch 2.0 with all the current commits, and switch to branch 2.1, where we will support PHP 7.2 and above. All further development of 2.x will be in the 2.1 branch, and 2.0, if necessary, will receive only security fixes.

[duncan3dc]

Bumping the minimum version of PHP is not a backwards compatibility break, it just means the new version will not install on old systems, composer handles this and developers don't need to worry about incompatibilities in the code.

Also 2.1 doesn't allow BC breaks either so using that version number doesn't make much sense

[StudioMaX]

Just tried this now with a test repo and it looks like you are right. Even if someone required james-heinrich/getid3:^2.0-dev, if the minimum PHP version in composer.json will be bumped to >= 7.2, then composer will just install the last available beta version (v2.0.0-beta3 as for now) for which we made the release. Apparently I'm used to the fact that before we did not have tagged beta versions at all, because of this, the composer always installed the latest commits from the 2.0 branch, or could not update the dependencies at all and rolled back with an error like this:

 Your requirements could not be resolved to an installable set of packages.
 
   Problem 1
     - Root composer.json requires studiomax/composer-test-dev-version ^2.0-dev -> satisfiable by studiomax/composer-test-dev-version[2.0.x-dev].
     - studiomax/composer-test-dev-version 2.0.x-dev requires php >=7.3 -> your php version (7.1.22) does not satisfy that requirement.