Emulate PHP 7's ability to allow specific exceptions be thrown on runtime assertion failure in PHP 5

Problem Summary

In PHP 7 a failed runtime assertion can throw a specific exception object like so.

assert( false, MyFailedAssertion );

Since we already have a handler in place to convert PHP 5 assertion failures into AssertionErrors we can use that handler to closely emulate this with the following syntax:

assert( false, '@Drupal\Component\Assertion\MyFailedAssertion');

This gets interpreted by the handler with the following tiny bit of code:

elseif (strpos($message, '@') === 0) {
          $exception_class = substr($message, 1);
          throw new $exception_class();
        }

Why Do This. The Goal

The above forms a bridge to PHP 7 while Drupal still must support PHP 5. It allows the feature of specific exception object on assertion fail throws to be used now by the codebase. When PHP 5 support is dropped these assertions can be converted over and any that aren't converted can be dealt with by the error handling subsystem.

Specific objects for assertion fails can provide us with much more detailed information about the reason of the failure, information far beyond the scope of a 1024 byte error string to convey. Such information can include

1. Relevant issue threads about the assertion, including the issue thread the assertion was created in.
2. Links to tutorials for working with configuration files when those can be used to cause an assertion failure.

Further, if the same general type of error needs to be checked for in multiple places of the code having a common object to throw is of enormous help.

Some of these concepts propagate out to general purpose exception objects as well - they too can carry issue thread and tutorial information on them. The reason to do this is to more properly leverage the Drupal community's information and get it to the programmers encountering difficulties with the system. The overall goal, lower the bar to learning, using and enjoying Drupal. Still, that's out of scope for this particular issue ticket which only deals with one tiny change that prepares the way for this larger concept.

Issues

I chose the @ character to start the message string because I don't think it is used in any existing assertion message string, and it's an unusual character. If someone has used it to start an error message then execution will crash for obvious reasons.

Unlike PHP, this emulation work around requires the fully qualified path of the exception object that will be thrown. There's no way around this but that is a minor gripe.

There are no other issues. Existing assertions don't *have* to be changed over since PHP 7 will accept a message string.

To Do

Though not attached I have a concept patch. I need to write unit tests for it but before I do I want to make sure everyone is on board with the concept overall and the syntax chosen above.