fix: Address most Clippy warnings

[tim-harding]

These categories of warnings were addressed:

• Automatic fixes from Clippy (cargo clippy --fix), such as removing redundant references
• Replace transmutes with safe pointer casts
• Remove lets that just get returned
• Add Default impl for types with new()
• Use iterators instead of indices
• Add Send and Sync bounds to dyn traits in Arc

There are still some warnings about documenting unsafe functions and returning references in new functions, but I think a separate pull request will be better for those since they probably require more discussion.

[MarijnS95]

Should the CI enforce these going forward? Otherwise you'll see such work being nullified sooner than later.

[waywardmonkeys]

This is pretty likely to conflict with my changes in #310. Not sure which will be more annoying to rebase atop the other.

[tim-harding]

@MarijnS95 Probably not yet. There are still some outstanding warnings that I mentioned in the post, so CI would not pass anything right now if Clippy warnings were denied. I don't mind a little whack-a-mole until we get to that point.

@waywardmonkeys I'm sure this refactor is distinctly lower-priority than yours, so I'd expect to be the one rebasing :)

Maybe this is the wrong place for it, but I have a couple of related questions. With functions like this

impl ArgumentDescriptor {
    pub fn new<'a>() -> &'a ArgumentDescriptorRef {
        unsafe {
            let class = class!(MTLArgumentDescriptor);
            msg_send![class, argumentDescriptor]
        }
    }
}

For the ones like the above that are giving warnings, shouldn't they return owned types? In the example above, the docs say that argumentDescriptor creates a new value, which I would assume causes a memory leak when the reference is dropped. The "you own any object you create" rule in the Memory Management Policy that the internal docs link to would seem to suggest that.

    #[cfg(feature = "private")]
    pub unsafe fn vendor(&self) -> &str {
        let name = msg_send![self, vendorName];
        crate::nsstring_as_str(name)
    }

Is there a safety contract for these private functions? It doesn't seem like there is actually any unsafe being used. If so, I will happily add the docs for them.

[waywardmonkeys]

@tim-harding My changes landed so this now has the promised conflicts!

[tim-harding]

I don't think I'm likely to work on this further for the time being. Thank you for your time.