Provide additional details to data processor

[twyatt]

Logging.DataProcessor now has 4 additional parameters:

• operation: Operation? (either: Write, Read or Change)
• service: Uuid?
• characteristic: Uuid?
• descriptor: Uuid?

These appear after the existing data: ByteArray parameter:

DataProcessor { data, operation, service, characteristic, descriptor ->
  // todo: process data
}

This allows library consumers to change their data processing behavior based on the characteristic or descriptor that the data was associated with.

For library consumers that don't need the new parameters, they'll need to update their custom data processors as follows:

DataProcessor { data, _, _, _, _ ->
  // todo: process data
}

Closes #532

---

Unit tests were added because the logging message builder had to go through an overhaul to add this support, so the unit tests provided some confidence that the output remained as expected.

[cedrickcooke]

If this is likely to get more fields added in the future, would be nice to wrap these up in a class of some sort. Would still be breaking now, but would make it non-breaking to add fields in the future.

[twyatt]

Admittedly I'm taking a "move fast and break things" mindset with this, partly because it feels warranted while pre-1.x — but mostly because I want to eventually ditch the data processor entirely in favor of #539. 🤷

[twyatt]

Added @ObsoleteKableApi to help warn consumers that this API will likely experience churn.