Removing ->dirty_folio

I think it's time to remove folio_mark_dirty(), ->dirty_folio() and so on.

This is not how filesystems want to be informed of folio dirtying.
It was fine for ext2, but anything that's journalled or COW has work
to do before the folio is made dirty, and it's hard to do that work
under the page table spinlock (not all callers hold that lock, but the
filesystem has to be able to handle the cases where it is.

Filesystems want the page_mkwrite() entry point to be how they find out
about a folio being dirtied -- and that works great!  Except that we
can writeback the folio for a number of reasons.  If it's been dirtied
due to a shared writable mmap, that's fine; we map the folio read-only
and any subsequent writes will re-enter the page_mkwrite path.

The problem is GUP.  We have no way to force the GUP caller to go
through page_mkwrite again.  So instead we make the GUP caller call
folio_mark_dirty_lock() which many just don't, and generally we get away
with it.  But it's a bug, and a bad interface.

There's also the problem that GUP users bypass the folio_wait_stable()
mechanism.  If a page is written to while somebody is creating a
checksum over that page, the checksum will be corrupted.  If we want
to fix this, we have to bounce-buffer the page.  There's no way to
prevent or delay a GUP user from writing to the page.  Enjoy your RAID.

My proposal is this:

 - Fileystems take note of folio_maybe_dma_pinned() during writeback.
   If it's true, do the writeback, but retain/recreate whatever data
   structures you need in order to write the folio again; behave as if
   ->page_mkdirty() had been called again for each page in the folio is
   marked as dirty.
 - The MM behaves similarly; we do not clear the writeback flag for
   folio_maybe_dma_pinned().

This will have the effect of writing pinned folios back every time the
inode is scheduled for writeback.  But since we have no idea whether
the folio is actually dirty (because the GUP user won't tell us),
this is the correct behaviour.

I'm probably missing some stuff here.  Let me know.