`commitAsync()` in `onPartitionsRevoked()`

`commitAsync()` in `onPartitionsRevoked()`

* Der Rebalance-Listener führt jetzt einen (zusätzlichen) Commit der
  Offsets durch.
* Ohne diesen Commit, kann es bei sehr hohem Nachrichten-Aufkommen dazu
  kommen, dass nicht die letztendliche Offset-Position gespeichert wird.
* Da jetzt implizit ein Commit in `onPartitionsRevoked()` durchgeführt
  wird, ist kein expliziter Commit mehr nötig, wenn der Consumer durch
  eine Exception unterbrochen wird, bei der sichergestellt ist, dass die
  zuletzt durch `poll()` gelieferten Nachrichten vollständig verarbeitet
  wurden.
** Bei einer `WakeupException` ist dies klar, da diese in `poll()`
   geworfen wurde, also _nachdem_ die Implementierung durch den Aufruf
   von `poll()` signalisiert hat, dass sie alle zuvor gelieferten
   Nachrichten vollständig verarbeitet hat.
** Bei einer `RecordDeserializationException` ist dies klar, da ein
   Fehler während der Deserialisierung der vom Broker empfangenen
   Nachrichten dazu führt, dass die Kafka-Client-Library die zuvor
   fehlerfrei deserialisierten Nachrichten ausliefert und dies auch
   entsprechend in den intern mitgeführten Offset-Positionen reflektiert.
* Der Commit wird hier asynchron durchgeführt.
* TODO: Das führt dazu, dass die Implementierung in dem Rebalance
  einfriert, da der Callback, auf den sie wartet, dort nie aufgerufen
  wird, da die Commit-Callbacks nur "synchron" abgearbeitet werden, wenn
  die `poll()`-Methode aufgerufen wird!