Add inner for NbtLists

[AronParker]

No description provided.

[Cassy343]

Thanks for taking the time to put up this contribution!

One minor nit: &Vec<T> is generally something you never see explicitly stated in Rust code, and this is because it creates a double indirection (one from the reference, and one from the Vec), and instead almost all of the time people opt for &[T] instead. Since every associated function accepting &self on Vec also exists for [T], I think it would be best to return &[NbtTag] here to avoid the anti-pattern.

That being said, NbtList already derefs to [NbtTag], so any method you'd want to call on an immutable Vec<NbtTag> can just be called directly on an NbtList (for instance my_nbt_list.chunks(2) is currently valid). I can understand adding this .inner() for consistency, but it shouldn't be blocking any use case, if that was the motivation for this PR.

[Cassy343]

Suggested change

	pub fn inner(&self) -> &Vec<NbtTag> {
	pub fn inner(&self) -> &[NbtTag] {

[AronParker]

Thank you for the swift response! That's true, I chose &Vec<T> just to be consistent but when thinking about it of course a slice makes much more sense. That deref flew right over my head, I was consulting on how to access the Vec and the documentation states that inner, inner_mut and into_inner are available for both NbtList and NbtCompound, but I hadn't realized that the inner of NbtList is actually done via a deref. That being said I think an inner wouldn't hurt for consistency and discoverability.

However, given that deref already provides the functionality of a slice, I do see one single use case where a slice wouldn't suffice (although I do admit it is very obscure). And that is when you have a &NbtList and you want to assert that no memory is allocated or that no panic is possible, you would have the option to check Vec::capacity() to see if it would fit before adding it. I do admit it is very obscure. Although one could also add capacity as a member for NbtList to resolve that problem. But I also believe from a consistency point of view having it return the same as the others makes sense.

That being said I really love this library, I think you guys nailed the design and how well and flexible goes together, I'm really fond of using it and love to see it being well maintained. I'd like to hear some comments on this and then will adjust my PR accordingly. Thanks for taking the time!