Deprecate php-4-style constructors

[derrabus]

In php 4 the name of the constructor function had to match the class name. php 5 introduced __construct() as new constructor function for classes that should be used instead.

Now, php 7 deprecates the php-4-syle constructors. That means, a E_DEPRECATED warning is triggered if such a function is still in use. Furthermore, a future php release (probably 7.1) will remove support for those constructor functions.

This PR adds __construct() to all classes. Since simply renaming all constructor functions will break code with classes that extend one of the Log_* classes, referring to the old constructor, the old constructor is kept in place, simply calling the new one.

I have also added a __construct() method to the Log class. This might seem a bit odd at first. I did that because php 7 interprets the presence of the log() method as old-style constructor (d'oh), so adding a __construct() method here avoids an E_DEPRECATED warning.

[CloCkWeRX]

I think it'd be OK to just drop the old style constructors entirely - we can just raise the min supported php version.

[derrabus]

The minimal php version right now is 5.2 (according to composer.json) or 5.0 (according to package.xml), which is just fine for the new constructors.

My intention was not to support lower versions of php. I simply did not want to introduce a breaking change. For instance, if someone would have written code like this:

class Log_my_special_file extends Log_file
{
    function Log_my_special_file($name, $ident = '', $conf = array(), $level = PEAR_LOG_DEBUG)
    {
        parent::Log_file($name, $ident, $conf, $level);
    }

    // Here be more dragons
}

This might not be the intended way to extend this library, but it's possible. If we now rename all constructors, that piece of code will break. This is why I left the old constructor functions in place, as a kind of compatibility layer. They don't hurt, yet you would give people with code like the piece above some time to migrate to the new constructors before removing the old ones in a later release.

[jparise]

I thought about this a bit, and I'm comfortable starting the 1.13.x release line with this change without the name-based compatibility layer. We can also use the opportunity to correct the inconsistent PHP version requirements.

[derrabus]

All right then, I'm going to remove the compatibility layer.

[derrabus]

The compatibility layer is gone now.

[CloCkWeRX]

Looking at the package.xml; php5+ is already required

[derrabus]

Any plans for a stable release with this patch?

[jparise]

Sorry for the delay @derrabus. I just published version 1.13.0.