Report addition of `trigger_error()` to a function's body as a BC break

[Ocramius]

Functions that are otherwise working fine cannot have trigger_error() expressions added to them, as that:

• breaks downstream consumers (output, loggers, test suites)
• introduces an unwanted side-effected, which could potentially cause major issues in a production environment

Therefore, we will add a new checker that ensures that trigger_error() additions are considered BC breaks.

[RikudouSage]

What about E_USER_DEPRECATED? That IMO shouldn't be a BC break.

[Ocramius]

That is pretty much the reason why this issue exists: userland deprecations in previously working code, breaking downstream consumers.

It's a dangerous and irresponsible approach perpetrated by symfony/* packages.

[RikudouSage]

I mean, if you don't configure your app to ignore deprecations you can't really blame anyone.

[Ocramius]

It's not just apps: it's a whole chain of libraries, tools and thousands of hours of work, just to stay in sync with side-effects introduced very deep in your stack frames.

For instance, in this specific library, a deprecation warning will break e2e tests, because STDERR is broken by those, and output buffering will catch them.

In other systems, an unrelated error listener may be tripped: potentially not even configured at application level, but deep in a library.

In other systems, performance may be crippled.

On systems that log all errors, disk space may become an issue.

In practice: don't add RUNTIME effects where none were present, because that is a clear BC break. We have the tools, and there is no need to make these problems a runtime side-effect.