Drop support for unsupported PHP versions

[shadowhand]

There are a number of optimizations that could be made to this package by dropping support for PHP <5.6 and even more by dropping support for PHP <7.0.

[mnapoli]

What do you mean by optimization precisely?

I see this package as a "base building block", unlike most other packages I maintain I try to keep it as unrestrictive as possible.

[shadowhand]

I noticed a couple of (micro) optimizations, for instance:

• equals() could use static::class instead of get_called_class()
• ditto for toArray()

Jumping to PHP 7 would also allow for strict typing for better runtime safety.

[Brammm]

Adding a 👍 for a PHP 7 version.

[mnapoli]

Copying my answer from #73 for reference:

---

I don't want to have a v2.0 unless it becomes absolutely necessary, here is an explanation:

Thank you for your work but I think a v2 would be damaging for the community as it would create a lot of conflicts downstream. If a v2 has enough value this would offset the pain, but at the moment I do not think it's worth it.

That being said we could upgrade to PHP 7.1 in a minor version (Composer will handle things without BC breaks for users). But I do not see actual value in that.

Don't get me wrong, I am the first to move every one of my open source package to the highest PHP version as possible, and I code daily with 7.2, I love it. But this package is very limited, very stable and very used. I don't see any gain for now. The amount of code is so small that adding a few typehints here and there doesn't seem that useful to prevent bugs. I want to leave it as stable as possible because it just works.

If a PHP feature allows us to do new useful stuff, or if it becomes obvious that typehints (or anything else) lets us catch some bugs that are not caught today, I will consider it. As long as there is no reason, I will let it like this.

[mnapoli]

We got a reason to upgrade to PHP 7.2 in #86 (and the work was done by a contributor) 🚀

I'll tag a new (minor) release.

[shadowhand]

@mnapoli what about adding return types to other methods? The current changes are already breaking and will require a major version, as equals() method signature has changed.

[shadowhand]

@mnapoli never mind, I read the PR again and I see that equals() is declared final, so minor version is possible.