Use newtypes from object crate

[philipc]

Hi,

I'm experimenting with adding newtypes to the low level API in the object crate. This involves significant numbers of breaking changes. The changes in this PR are a result of investigating the impact on wild, and I'd like your feedback on whether you consider these changes acceptable.

wild already defined a few newtypes, and this PR replaces their definitions with a reexport of the types from object. Similarly, the constant definitions become reexports too. The API that object provides is similar to wild's newtypes with a few differences:

• .0 instead of .raw
• read fields directly instead of using from_header
• object's Debug implementation keeps the prefix in the names (I can't see a way to avoid this without using proc macros)
• object doesn't provide Display implementations - these are application dependent, so wild now uses Display wrappers just for that

The motivation for adding these newtypes in object is I guess the same reason that wild added its own: convenience methods and the Debug impl, as well as general type safety benefits.

For reference, the object PR is gimli-rs/object#878. This PR is still far from complete, so there are likely to be more changes needed in wild as other newtypes are added. I'm happy to do all the fixes needed in wild if this work proceeds.

[davidlattimore]

Looks good to me. Thanks for updating our code!

We're also happy to merge the change sooner and temporarily depend on object from github if you'd like to avoid merge conflicts. We're intending to release wild 0.9.0 in the next few weeks, but there's still a few things we want to fix first. We could merge your PR before 0.9.0 provided you were expecting an object release within a couple of weeks, or if we merge after 0.9.0, then we've likely got more leeway.

[philipc]

Thanks for taking a look, I'll keep working on it. I don't want to commit to any timeframe yet, so better to hold off merging anything for now.