add better EventLoopPreference names

Right now, we have three (public) EventLoopPreferences:

1. .delegate(on: EventLoop)
2. .indifferent
3. .delegateAndChannel(on: EventLoop)

I did propose this naming personally so I feel a little sheepish for proposing to change (or just add better) names. But let me explain how we got here:

When I proposed this, I thought that the user only wants to choose the EL for the delegate callouts. To use AHC however, a user needs more guarantees. Almost all users will want to specify an EL and they require the following things to happen the specified EL:

• Task.futureResult needs to be bound to the specified EL
• all delegate methods need to be called on the specified EL
• all other callouts need to be called on the specified EL

Today (and in the future), .delegate(on: el) does exactly that. The naming however is confusing because it only mentions the delegate (but not the future or other callouts).

My new proposed naming is:

1. .on(EventLoop)
2. .indifferent
3. .forceChannelAndCalouts(on: EventLoop)

Maybe to reduce the number of deprecation warnings we should do

1. .on(EventLoop)
2. .delegate(on: EventLoop) (same as .on(EL))
3. .indifferent
4. . forceChannelAndCalouts(on: EventLoop)
5. .delegateAndChannel(on: EventLoop) (same as . forceChannelAndCalouts(on: EL))

I think we need to focus on the 99% case and the 99% case is that users really don't care where the Channel lives but they very much care where the future and all the callouts come from.

That means that we mostly need to focus on the name of the 99% case and I think eventLoopPreference: .on(myEL) is great.

All the other cases (2 - 5) are really for special uses so it's actually good if the names are slightly longer.

Start by locating the public EventLoopPreference declaration and its usages, then review how the proposed .on, .delegate, .indifferent, and .forceChannelAndCallouts names map to the existing cases. Check the public API and compatibility implications, including whether deprecated aliases are needed; done means the naming choice and its migration behavior are agreed and consistently represented.