Remove unnecessary usages of the vec! macro

[edmorley]

For cases where a known-at-compile-time length array is being passed to a function that accepts an Into<Iterator>, there is no need to wrap the array in a vec![] invocation.

I spotted a couple of these in one of the newly added libcnb-test tests, and a search and replace later it turns out there were quite a few more instances of this than I was expecting!

GUS-W-14160950.

[Malax]

Unsure if I'd agree that vec![] is worse than Vec::new() when we need to create an empty Vec. Seems insignificant to me. At the same time if you feel strongly about this I'm happy to approve.

👍🏻 on the changes where we save allocating a Vec! :)

[edmorley]

More context from Slack:

[Ed] I can see an argument for using either. The reasons I lean towards Vec::new() are that:

• Most types don't have a macro form, and instead only have the ::new() variant, eg HashMap::new(), so it seems more consistent to always use the ::new() form
• The vec! macro to me implies "we're creating a constant length non-empty thing at compile time, otherwise we'd be dynamically pushing into a vec at runtime". eg like String::new("") would be weird to use vs String::new()
• Fewer macros means less for the compiler to do (I don't expect this change to make any difference, but as general principal if there's two options that are virtually identical from a verbosity/UX point of view and one means using a macro and the other doesn't, then I think I would generally pick the non-macro option)

There are some additional thoughts in https://www.reddit.com/r/rust/comments/fs1g5h/vec_or_vecnew/

I didn't originally intend to make the additional vec![] -> Vec::new() changes but it got picked up by the search and replace (of the outright vec! removals), so I went with it (since I've thought about changing them before, but decided not worth the effort on its own)