Restore Netty's channel-option failure semantics in ChannelManager

[hyperxpro]

Summary

Follow-up to #2219. That PR stopped setting channel options on the shared
Bootstrap and instead applies them per-channel from AHC's channel initializer
via Channel.config().setOption(...) in ChannelManager.applyChannelOptions, to
avoid Netty's per-connect synchronized (options) copy in
AbstractBootstrap.newOptionsArray() (issue #2218).

The new applyChannelOptions called setOption directly, which silently dropped
the error-handling that Netty's AbstractBootstrap#setChannelOption provides.
Compared to the previous Bootstrap#option path this changed behaviour on the
error path only:

• Unknown option key (setOption returns false): previously logged
  "Unknown channel option ..."; now completely silent — a mistyped entry in
  config.getChannelOptions() produces no warning.
• setOption throws (bad value / unsupported on socket): previously logged
  "Failed to set channel option ..." and, with CLOSE_ON_SET_OPTION_FAILURE
  defaulting to true, failed the connect with the real cause. Now the throwable
  propagates out of initChannel, where ChannelInitializer logs a generic
  "Failed to initialize a channel" and closes it — so the connect fails with a
  masked cause and no option-specific diagnostic.

Fix

Mirror Netty's AbstractBootstrap#setChannelOption in applyChannelOptions:

• warn and skip on an unknown option key (setOption returned false);
• warn (naming the option + value) and rethrow on failure, preserving Netty's
  close-on-failure semantics so a channel never connects with a half-applied
  configuration.

Happy-path behaviour is unchanged. Only user-supplied config.getChannelOptions()
can hit these branches; the built-in defaults are all guarded to valid ranges.

Compiles clean on JDK 11 (./mvnw -pl client -am compile).