…ssageIdData

Master issue: apache#18950

### Motivation

We need a common interface to get fields of the MessageIdData. After
that, we won't need to assert a MessageId implementation is an instance
of a specific class. And we can pass our customized MessageId
implementation to APIs like `acknowledge` and `seek`.

### Modifications

- Add `MessageIdAdv` to get fields of `MessageIdData`, make all
  MessageId implementations inherit it (except `MultiMessageIdImpl`).
- Add `MessageIdAdvUtils` for the most common used methods.
- Replace `BatchMessageAcker` with the `BitSet` for ACK.
- Remove `TopicMessageIdImpl#getInnerMessageId` since a
  `TopicMessageIdImpl` can be treated as its underlying `MessageId`
  implementation now.
- Remove `instanceof BatchMessageIdImpl` checks in `pulsar-client`
  module by casting to `MessageIdAdv`.

After this refactoring, the 3rd party library will no longer need to
cast a `MessageId` to a specific implementation. It only needs to cast
`MessageId` to `MessageIdAdv`. Users can also implement their own util
class so the methods of `MessageIdAdvUtils` are all not public.

### Verifications

Add `CustomMessageIdTest` to verify a simple MessageIdAdv implementation
that only has the (ledger id, entry id, batch idx, batch size) fields
also works for seek and acknowledgment.