With e000bd7, we can also close scijava/scijava#64

Over in scijava/scijava#13, @ctrueden said:

here are valid reasons for wanting to log, for example, only a single op at debug, but everything else at info or warn, because you really just want to debug that one op implementation. Being able to do this without changing/rebuilding any code can be really important in some deployment scenarios.

With this PR, you'd do something like the following:

var theExistingLogger = Logging.getLogger();
Logging.setLogger(myVeryVerboseLogger);
ops.op("some op I want to debug").arityX().inputs(...).apply();
Logging.setLogger(theExistingLogger);

What would you prefer? Something like:

var op = ops.op("some op I want to debug").arityX().inputs(...).function();
Logging.setLogger(op, myVeryVerboseLogger);
op.apply(...)

I don't feel too strongly one way or the other - honestly, it wouldn't be too terribly hard to add the other, if that's what you think people will use.

There are also valid reasons for wanting to have a different logger used per OpEnvironment, in case you have some complicated server-side JVM running multiple separate contexts.

This seems like something that the AbstractRichOp could be responsible for doing. Do you really foresee someone doing this? I'm happy to punt on this until it's needed.

From an architecture standpoint, I can't say that I love having a static Logging utility class—I think it limits the utility of logging—and we might be better off just going with a "standard best practice" logging approach that doesn't try to be too clever about reducing boilerplate. E.g. just suck it up and put the SLF4J Logger declaration at the top of each class that wants to do logging, I dunno...

Isn't this basically what we're doing now?

Discussion in scijava/scijava#13 looks unresolved. I'm going to move this to a draft PR and remove the reviewers for the moment until we have a chance to discuss further.