Make location computation and message formatting more lazy

[ppkarwasz]

We move the computation of location and message formatting to the last method call executed before a message leaves the current thread.

This has several consequences:

• the refactoring of location computations should solve AsyncLogger does not compute location for some methods #1458,
• since AbstractLogger no longer needs to compute the location of the caller, many messages were refactored to fit in the 35 bytes of bytecode limit. Only logIfEnabled methods with 4 or more Object parameters are over the limit and logMessage methods with 8 or more Object parameters, handleMessageException and the constructors,
• messages that are filtered out by e.g. the filter of AsyncAppender do not include location information.

Part of #2290.

[vy]

Great simplification @ppkarwasz! 💯

1. Since the Message is already populated with a loggerFqcn and that is enough to resolve the location in the LogEvent, we don't need to resolve the location in AbstractLogger, right?
2. Due to to peekSource(), when a message gets copied elsewhere, peekSource() can be used to initialize the source, and reuse the already populated value, if present. Otherwise, getSource() can calculate it, if requested. This is the crux of this locate-at-the-end implementation, right?

[vy]

Shouldn't this also be annotated with @Nullable too? (Applies to other getSource() changes delegating to peekSource().)

[ppkarwasz]

1. Since the `Message` is already populated with a `loggerFqcn` and that is enough to resolve the `location` in the `LogEvent`, we don't need to resolve the location in `AbstractLogger`, right?

Right. Having the FQCN of the logger class allows us to retrieve the location at any time or never.

Previously the location was computed eagerly based on the result of requiresLocation(). This method can tell us if location information will be necessary, when the message will be logged. However it can not tell if the message will be logged at all.

2. Due to to `peekSource()`, when a message gets copied elsewhere, `peekSource()` can be used to initialize the `source`, and reuse the already populated value, if present. Otherwise, `getSource()` can calculate it, if requested. This is the crux of this locate-at-the-end implementation, right?

Partially, the original getSource() method was introduced when location was a binary choice: you could either compute it and log it or neither compute it nor log it. However the LogBuilder#withLocation method changed this: we can know the location without computing it.

If we just keep the getSource() method and the user sets includeLocation == false on a component (which means "do not compute location), we need to be extra careful while calling getSource:

boolean oldIncludeLocation = event.isIncludeLocation();
event.setIncludeLocation(false);
event.getSource();
event.setIncludeLocation(oldIncludeLocation);

The peekSource is a way to make the process easier.