Worker: think about compiler logging

In the CLI, back in the day, I was adamant that we should take steps to explain what's happening in compilation. Thus the compiler would log when it changes the user's code (although not consistently! It really only does it for the imports)

That's because the CLI is focused very much on engineers and I want them to understand what happens to their code.

In the app, things are a bit different. Compilation is an annoying detail that app users likely don't need to know about (some engineers will, but they should be able to switch on debug logging).

A few thoughts here:

• Log filtering doesn't work in the app like it does in the CLI. The spec handed to the lightning team was wrong. So you can't filter on "success" or "always", and the logging isn't graded properly so you don't get a default of success/error/warning like in CLI. I mean really we just want debug or normal.
• For now I've removed some compiler logs entirely, but really they should be filterable. In the CLI there's an awkward command to set the log level just for the compiler (if you don't care about compilation, you probably want all compiler logs off, except perhaps the headlines). But no equivalent in the app.
• Part of the the problem is that there's a log level per component, but not all components are equal. Job logs are always going to be different to compiler and linker logs

I wonder if we just need to add a second switch to lightning to filter logs by component.

The issue names the CLI, app, Lightning logging, and compiler, but no files, tests, or concrete entry points. Start by tracing the existing CLI and app logging behavior and reviewing the logging specification described in the issue. Done requires an agreed design for component-aware compiler logging and corresponding filter behavior.