DebuggableThreadPoolExecutor does not propagate client warnings

Extracted this as a separate ticket per discussion on CASSANDRA-17044

The problem is in DebuggableThreadPoolExecutor - it does not propagate executor locals to the thread when tracing is disabled. It is probably expected that we propagate the state if at least one executor local is defined, but we only check for tracing and completely ignore client warnings.

The attached PR fixes the problem, adds some tests and reverts a workaround for client warnings in some schema alteration statements implemented in CASSANDRA-16296 (described below).

Old description - still valid, but this is just a manifestation of the problem rather than the problem itself

This seemed to be screwed a bit. In just two schema alteration statements we collect client warnings which are captured during the transformation into a local collection.

I guess it is done that way because the transformation is being executed in a different stage (migration) and client warnings collected in that stage are not present in the stage where the query is executed.

Then, the client warnings are retrieved using clientWarnings method and added to the captured client warnings in the stage which is executing the query.

This mechanism was implemented only in two schema alteration statements. It is possible that for other ones the client warnings can simply get lost.