Allow conditional Send futures in future_not_send

[y21]

Closes #6947

This changes the lint to allow futures which are not Send as a result of a generic type parameter not having a Send bound and only lint futures that are always !Send for any type, which I believe is the more useful behavior (like the comments in the linked issue explain).

This is still only a heuristic (I'm not sure if there's a more general way to do this), but it should cover the common cases I could think of (including the code examples in the linked issue)

changelog: [future_not_send]: allow conditional Send futures

[rustbot]

r? @Alexendoo

rustbot has assigned @Alexendoo.
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

[Alexendoo]

Do we think people will enable this config? I can't come up with a good case it would catch

[y21]

Not sure, probably not. The only thing I could think of is potentially better errors at the definition/call site directly if everything is required to be Send, instead of having the !Sendness propagate to the final future passed to tokio::spawn(), but it's probably not worth it

[y21]

The ICE path isn't really reachable anymore for this test since the function is generic so I'm not sure it's still useful to have, and if I understand the original ICE correctly it would have happened for all the regular tests anyway (anything that led to the .err_ctxt() call)?

[y21]

I left the config option in as a commit for now in case it's still useful but I'll squash it away before the merge

[Alexendoo]

Looks good! Can r=me after the squash