Services decorating a LoggerAwareInterface service no longer need to implement LoggerAwareInterface themselves

The bug

LoggerAwarePass required
every service tagged 'logger_aware' to implement
LoggerAwareInterface, throwing InvalidArgumentException
otherwise. Decorating such a service is normal, supported Symfony usage
- but decoration inherits the 'logger_aware' tag onto the decorator, which
usually doesn't implement that interface. The result: adding an
ordinary logger decorator anywhere in the container failed the entire
container compile, not just that one service - e.g. any module
decorating `logger.console` (DrupalConsoleLogger,
which does implement the interface) broke every `drush` invocation on
the site.

What changed

LoggerAwarePass now finds the undecorated instance through the
new InstanceAliasing mechanism (see the companion change record)
instead of trusting whichever definition currently holds the
'logger_aware' tag. A decorator no longer needs to implement
LoggerAwareInterface (but it may and gets setter injection if it does).

The misconfiguration check that made sense before decoration was
supported is preserved for the case that's still a real error: a
non-decorator service hand-tagged 'logger_aware' without implementing
the interface. Its exception message now also includes the offending
class name, not just the service id, to make that case easier to debug.

Nothing to do for existing code

This is transparent to existing code (no API changes).
If you were previously bothered or blocked by this, it's fixed.