Simplify saving logic and make it well behaved

[RGBCube]

Previously, Helix did the following when we saved a file:

1. Created a .bck (backup) file, copied the original's contents over.
2. Re-created the original, empty this time. Then wrote to it.
3. If writing or creating failed, it moved the backup back into the original file.
   3.1. Though, it did different stuff for hardlinks. Also not ideal.

The issue here is that if helix crashes / gets killed while executing
step 2 or 3, the file would be in an inconsistent state. This is not ideal
at all, file writing isn't atomic with this strategy.

This patch simplifies this logic into:

• Create a temporary file, write the stuff we want to write into it.
• If that fails, we don't need to do anything as the original file is
  untouched. (Though we do delete that tmp file if writing to it or moving it in-place fails)
• If it is successful, we rename the temporary file over the actual
  write destionation. This is atomic, and if it fails the destination is
  unmodified.

There are also other benefits from doing the latter, such as inotify.
Previously, we would get these events for an edit of .cargo/config.toml:

Create /Users/pala/Projects/helix/.cargo/config.toml.bck
Write /Users/pala/Projects/helix/.cargo/config.toml.bck
Create /Users/pala/Projects/helix/.cargo/config.toml
Write /Users/pala/Projects/helix/.cargo/config.toml
Remove /Users/pala/Projects/helix/.cargo/config.toml.bck

Now, we get these:

Create /Users/pala/Projects/helix/.cargo/config.toml.tmp
Write /Users/pala/Projects/helix/.cargo/config.toml.tmp
Write /Users/pala/Projects/helix/.cargo/config.toml

This is better and easier to handle, because inotify events
actually look like we are writing to the target file, instead of
re-creating it.

[RGBCube]

I removed the tempfile dependency and added fastrand (which it used internally). Any suggestions on eliminating that crate?

[the-mikedavis]

Saving is not simple and has a lot of edge-cases. This doesn't work with hardlinks, for example: the hard link is destroyed. Instead of writing something novel we should be moving closer to what established editors do, like in #11374

[RGBCube]

That's interesting, the main thing that got me to do this was inofity, where Emacs did what was done in this PR. I'll take a look at what it does too, and comment on that PR if necessary