WL#8756: Deprecate binlog_max_flush_queue_time in 5.7

The variable binlog_max_flush_queue_time was introduced in 5.6 in order to fine-
tune the Binlog Group Commit. Due to changes in 5.7, the option has no effect any 
more. Therefore we deprecate the variable in 5.7 and plan to remove it in 5.8.

This worklog will generate a deprecation warning in 5.7 and 5.8. It will not 
remove the variable in 5.8.

FR1. Use of binlog_max_flush_queue_time should generate a deprecation warning.

Details:
- In 5.6, in the flush stage, the leader thread processes the queue while other
  threads are allowed to concurrently append themselves to the queue. In order
  to avoid that the queue grows indefinitely (in case there is a big number of
  clients), the processing is limited by a timeout, specified by
  binlog_max_flush_queue_time. When the timeout is reached, the leader fetches
  the entire queue and processes it without allowing other clients to add to the
  queue. (It has to process the remainder of the queue since there is no other
  leader thread that can do that.)
- In 5.7, the flush stage was rewritten for improved performance. Now,
  ha_flush_logs (which typically flushes and syncs InnoDB's redo log) is done 
  in the BGC flush stage prior to processing the queue, rather than in the
  engine's prepare phase. Therefore, the leader thread must not allow other
  threads to add to the queue while processing the queue (ha_flush_logs
  would not be called for those other threads). And again, the leader thread
  has to process the entire queue since there is no other leader thread that
  can do that. So the leader must process the exact queue as it was when the
  leader entered the stage; neither more nor less. So we cannot have a timeout.
- It was discussed whether the flush stage could be rewritten so that the
  timeout would be useful. One possibility could be: after the leader has
  processed the entire queue, it checks if more threads have entered the stage.
  In that case, it restarts the stage, calling ha_flush_logs for the new threads
  and then flushing the new threads. So then concurrently committing threads
  could join the leader's group during the flush stage, and there may be a use
  case for the timeout. However: we have no time to implement this in 5.7 so
  the option will for sure remain unused in 5.7. It is also unclear if this
  would give much improvement (we would have to measure), so it may never be
  implemented. Better then that we deprecate in 5.7 and in the unlikely case
  that we implement this in 5.8, we remove the deprecation warning.