WIP: BREAKING CHANGE: Store byte offset in `Error` instead of `TextPos`.

[Jayonas]

This adds support for error handling scenarios where callers need the byte offset where an error occurred rather than the TextPos. Since TextPos is calculated from a byte offset (and the source string), the best way to provide support for both situations is to store the byte offset in Error and then supply an easy way for the caller to translate it into a TextPos.

FIX: Callers that want to continue displaying the TextPos (i.e. line/col) for an error will need to refactor their error handling code to create that TextPos by calling the new text_pos free function, passing the original XML string and the result from Error::pos() (which is now a usize instead of a TextPos).

Breakdown of changes:

• Change all TextPos data in Error to usize.
• Change Error variants without position data to return 0 from pos method.
• Remove position info from Error Display strings, allowing the caller to provide position info in the manner of their choosing. Rephrase a few error strings where the position was in the middle of the string.
• Fix up all the places that create errors.
• Refactor Stream::gen_text_pos[_from] and Document::text_pos_at into new lib-level free function text_pos.
• Refactor text_pos_* tests in tokenizer_tests to just test the new text_pos function. Move them to the api tests and renumber them to not conflict with the text pos tests already in that file.
• Add position field to Token::Error in tokenizer_tests so that expected error positions are still verified even though they're not included in the Display strings anymore.
• Change ast test function to concat error strings and their TextPos before comparing to the expected file/message.

Questions:

• When I rephrased error messages it was pretty mechanical, better suggestions are welcome.
• The changes in ast tests were the minimal needed to get them working without losing functionality. I suggest that it might be preferable to store the expected byte position separately from the message in the yaml file, but I'm not sure what the preferred way to do that would be.