feat: add byte tracking

[OGKevin]

This commit introduced a new feature flag that enables the ability to track byte offsets.

When the source-positions feature is enabled, the tokenizer will track the number of UTF-8 bytes consumed from the input. This is done by giving BufferQueue a bytes_consumed field, which is incremented every time a character is consumed.

The changes in cargo.toml were needed to make this project load as a git submodule in the Cadmus project.

The xhtml-self-closing feature was needed due to EPUBs using XHTML-compatible self-closing on RCDATA/RAWTEXT elements. (baskerville/plato#426 (comment))

Change-Id: 566446e2bca101b7fefdca639c1b4d26
Change-Id-Short: uttvvtlxonpy

---

🤖 was used to generate some of the rustdocs and tests. Was also used to educate me on the project and brainstorm implementation path.

---

I have a local branch in Cadmus that added this project as a submodule, works great and seems to not break anything, need to do some more testing by daily driving and asking others to test. (Will cross link once I open PR there, needs a tiny bit of more work)

I'll leave this in draft, so it won't get merged by accident, but I'm ready to get feedback on it. Will mark it as ready once I finish with the changes in Cadmus.

---

Closes: #734

Ref:

• Byte-accurate source positions in TreeSink #734
• Migrate EPUB HTML parsing from XmlParser to html5ever OGKevin/cadmus#384

[simonwuelker]

🤖 was used to generate some of the rustdocs and tests. Was also used to educate me on the project and brainstorm implementation path.

Note that servo does not accept AI-generated contributions: https://book.servo.org/contributing/getting-started.html#ai-contributions.

Admittedly we should do a better job of communicating that this applies to all repositories under the servo org, not just servo/servo.

[OGKevin]

Ahh, that might make things interesting now. I wasn't aware, mybad.

What now? As I see 2 solutions:

1. Remove the tests and rustdocs, as thats the easiest way to remove all 🤖 touched code, but would also significantly lower the quality of the PR.
2. Re-write them, but I'm now biased to what I've seen, reviewed and agreed with, so my manual rewrite might not be significantly different. Unless you have some feedback on it that makes it look diff. However, how would I then proof that was scaffolded by 🤖 is now 100% manually typed?

The tests turned out to be useful as they caught some gaps in the implementation, but since they've "served their purpose" I'm fine with removing them. As In this specific situation, I've similar tests in Cadmus that covers similar cases.

Do note that tests are the biggest diff:

---

I'm not challenging the usage of 🤖, just not sure how to move forward. Unfortunately, my daily life has come to 🤖 code reviewer. So I take the small manual implementations where I can, was just lazy when it came to tests and rustdocs 🙉 😭.

[simonwuelker]

I'd be fine with you rewriting the tests and rustdoc.

but I'm now biased to what I've seen, reviewed and agreed with, so my manual rewrite might not be significantly different.

That's okay.

However, how would I then proof that was scaffolded by 🤖 is now 100% manually typed?

You don't need to prove that. We rely on the honesty of contributors when rejecting AI generated patches (unless the patch is obviously slop). Thanks for being upfront about it.