Make trivial-copy-size-limit consistently the size of the target pointer

[Alexendoo]

Fixes https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Ambiguous.20default.20value.20for.20.60trivial-copy-size-limit.60

The current situation is

Target width	trivial-copy-size-limit
8-bit	2
16-bit	4
32-bit	8
64-bit	8

Since practically speaking it's almost always 8, let's go with that as the unconditional default to make it easier to understand

Now defaults to target_pointer_width

changelog: [trivial-copy-size-limit] now also defaults to the size of a target pointer (unchanged for 64-bit targets)

[rustbot]

r? @Jarcho

rustbot has assigned @Jarcho.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Jarcho]

The original justification for limiting it to eight on 64-bit targets was quite flimsy. It makes (usize, usize) ok on everything but 64-bit targets. This means something like struct S(&'static [u8]) is too big to pass by value, which is rather ridiculous.

It would be nice if the lint could be target independent, but struct sizes already aren't.

[Alexendoo]

This means something like struct S(&'static [u8]) is too big to pass by value

It means it's not small enough to lint, not that it's too big to pass by value. That's a separate config pass-by-value-size-limit

[Jarcho]

Sorry I had lint/not lint backwards (was half thinking of large_types_passed_by_value). &S would be trigger trivially_copy_pass_by_ref on 32-bit targets, but not on 64-bit targets. Basically fat pointers should behave consistently.

[bors]

☔ The latest upstream changes (presumably #13286) made this pull request unmergeable. Please resolve the merge conflicts.

[Alexendoo]

Changed it to be the width of the target pointer, this halves the limit for smaller targets but keeps 64-bit the same

Increasing 64-bit's limit is also an option, but it led to many more cases being linted