Bumps [org.assertj:assertj-core](https://github.com/assertj/assertj) from 3.27.6 to 3.27.7.
- [Release notes](https://github.com/assertj/assertj/releases)
- [Commits](assertj/assertj@assertj-build-3.27.6...assertj-build-3.27.7)

---
updated-dependencies:
- dependency-name: org.assertj:assertj-core
  dependency-version: 3.27.7
  dependency-type: direct:development
...

Signed-off-by: dependabot[bot] <[email protected]>

Closes #396

#129

#400

Fixes: c1478fa

#400

Bumps [org.bouncycastle:bcprov-jdk18on](https://github.com/bcgit/bc-java) from 1.83 to 1.84.
- [Changelog](https://github.com/bcgit/bc-java/blob/main/docs/releasenotes.html)
- [Commits](https://github.com/bcgit/bc-java/commits)

---
updated-dependencies:
- dependency-name: org.bouncycastle:bcprov-jdk18on
  dependency-version: '1.84'
  dependency-type: direct:development
...

Signed-off-by: dependabot[bot] <[email protected]>

As discussed in the issue below, the library currently exposes character strings only as escaped strings for textual representation. This is a limitation as users are forced to deal with unnecessary escapes for application logic, and are also limited to interpret bytes as UTF-16 (as `byteArrayToString` casts bytes to `char`), whilst RFCs do not state which encoding for bytes should be used.

This commit adds:
- `getXxxAsByteArray()` getters that expose the "raw" byte array, allowing full control to users. This follows the already established pattern in 'TXTBase` with the `getStringsAsByteArrays()` method
- an overload of the existing getters, which allows to pass an `escape` boolean: `true` (the default) is the current behavior, while `false` simply converts the bytes to a String using the UTF-8 encoding

Closes #404