Drop backwards-compatibility layer

[greg0ire]

Draft PR because I don't actually want to get this merged, this is just to show what the diff with 1.4.x is, and to (hopefully) get a green build. If this looks ok, then we could move 2.x to 3.x, and this branch to 2.x

[greg0ire]

A quick grep shows that this is very far from complete 😅

[greg0ire]

It also shows that another PR needs to be done to update the docs: they still refer to the outdated namespace.

[greg0ire]

Regarding the docs, see #107

[alcaeus]

If this looks ok, then we could move 2.x to 3.x, and this branch to 2.x

Note sure if that's necessary. IMO, the following works fine:

• 1.3.x: Introduces new API and uses @deprecated annotations on deprecated code paths (already done)
• 1.4.x: Keeps new API, introduces @trigger_error calls to announce deprecations loudly
• 2.0.x: Drops legacy API, introduces parameter types (as those are ok to be removed when inheriting). Documentation informs people to add return types to inherited methods
• 3.0.x: Introduces return types to all methods

[greg0ire]

My main point with this PR is that I don't touch dependencies version constraints, including and especially the php one, and that's what would make bumping to 2.0 and dropping the *_exists calls from the ORM (for instance) acceptable.

[alcaeus]

Ah, I see. So we'd be postponing the argument types to 3.0 to avoid dropping PHP 7.2 in 2.0, because that would make it ineligible for ORM 2.7? My head is spinning, but I think I understood.

[greg0ire]

Yes, that's exactly my point. Note that it indeed means postponing argument types to 3.0, but that 3.0 can and should still happen very soon IMO. It's just that there would be an easier-to-upgrade-to intermediary step.

[alcaeus]

If it makes upgrading ORM easier, sure :)

[greg0ire]

I pushed this as 2.0.x :)