Support for lossy MachO parsing

[h33p]

Made it possible to parse MachO objects in less strict manner. However, default behavior is not changed. Therefore, there now is a new function parse_2 which accepts additional argument for lossyness.

Open questions:

• Is the default behavior intended? If not, parse_2 could be made private.
• Is parse_2 sufficient name, or should this be called something like parse_lossy?
• I made all of the commands work without fail in lossy mode, however, maybe some should fail?
• Should from_32_2 from_64_2 on Segment be exposed to the public? I currently have it pub(crate).

[m4b]

interesting PR, thank you! so as per the comments, I don't want to expose a parse_2 name publicly, needs to be parse and parse_lossy or something, with the parse_impl getting forwarded whether it's lossy or not.

the only other consideration is whether you want to think about future lossy parsing, where a config is passed in to the lossy form, and this determines which things get dropped/ignored, etc., though that might be overkill, i don't know.

I'm also not totally sold on the lossy name, but it's ok.

Some other random alternatives that are probably worse names:

1. strict/unstrict
2. infallible

all said and done lossy is probably the best name?

Elf also has a similar, but slightly orthogonal support for "lazy" parsing, which doesn't parse the whole thing, but iirc, this was ostensibly to allow infallible parsing when some parts are broken/let user decide if they want to fail or not, may want to look at that, so we have a more unified api/approach to lossy/infallible/lazy parsing?

[h33p]

Thanks for review, finally got around addressing your comments. Please let me know if you need anything else.

[m4b]

Test would be nice for this if you have time, otherwise lgtm

[m4b]

@h33p CI is failing on rustfmt

[m4b]

once format fixed this is good to go

[h33p]

This should be good to go now @m4b

[m4b]

thanks!

[m4b]

note: non-breaking

[m4b]

released in 0.8.1