Avoid failing if an exports trie symbol name cannot be decoded as UTF-8

[PaulDance]

Whenever one calls ExportsTrie::parse on a data bytes slice containing a trie with non-UTF8 strings, for example if UTF-16 is encountered, Err(Error::FromUTF8Error(...)) is returned. This makes the whole parsing fail while as far as I known it is not strictly-speaking a parsing error as nothing requires trie strings to only be valid UTF-8. At least, I did observe in the wild some macho files with UTF-16 trie strings that do run under macOS.

It would be nice if there was a way to get symbols with the name left as raw bytes instead. This way, the user would be able to decide what to do with the bytes instead of having the parsing decide that for them.

This could potentially be achieved by adding some kind of new lower-level API somewhere that would be orthogonal to the already-existing one. From what I've seen, only the calls to <Cursor as CursorExt>::read_cstr would need to be changed. This could be a lead to follow in order to avoid duplication between the two APIs as much as possible.