Refcounting dma_resv v3

["Christian König" <ckoenig.leichtzumerken@gmail.com>]

Hi everybody,

The idea of ref-counting dma_resv or ww_mutex came up multiple times from
different people, but so far at least I have abandoned that as to
complicated to implement considering how widely used that object is.

Thanks to AI I gave the task to refcount dma_resv to Claude Sonet 4 just
to check how horrible it would look like.

Well turns out that this is actually a cleanup we should most likely aim
for and I'm really wondering why we haven't done it like this in the
first place.

Not only resolves it a bunch of issues with dma_resv instances shared by
multiple GEM objects (we just recently had a bunch of patches for that on
the mailing list), but also allows TTM to implement it's delayed delete
handling without any zombie resurrection or similar hacks and DMA-buf to
have better contention handling on map/pin in the future.

v2:

This patch set here is now the idea full flashed out. I smoke tested it
with amdgpu, self tests and checked everything with kmemleak and of hand
it seems to work.

Patch #1 introduces an interim allocated flag to allow switching users
over to the new interface one by one. Patch #10 then removes that flag
again after everything is done.

v3:

Well distrusting Sonet proved to be correct. It turned out that the AI
missed tons of issues. Most of them are hopefully fixed in this
iteration of the patch set now.

Sashiko-bot on the other hand proved to be extremely useful. It not only
pointed out tons of stuff Sonet missed but also a complicated pre-existing
bug in i915.

The first patch in this series is now fixing this i915 bug, I've send
this to the relevant mainatiners separately and only include it here for
completeness.

Please review and comment.

Cheers,
Christian.