std.fs: Absorb IterableDir into Dir

[andrewrk]

This reverts #12060.

I was against this change originally, but approved it to keep an open mind. After a year of trying it in practice, I firmly believe that the previous way of doing it was better.

Furthermore, I took this opportunity to extract Dir and AtomicFile out from fs.zig into Dir.zig and AtomicFile.zig respectively, and also to flatten std.fs.file.File into std.fs.File.

[squeek502]

I think extracting Dir is a good change, but I think it will also increase confusion about the Absolute suffixed functions since they will seem like they have precedence being in the std.fs namespace proper (#16736).

EDIT: Nevermind, I was thinking about this wrong. The difference will only show up in the source code, the namespaces are still the same. People still might be (incorrectly, imo) drawn towards the Absolute functions if they're looking at fs.zig directly, though.

Would like to get your thoughts on my comment here while you're thinking about std.fs

[nektro]

I was against this change originally, but approved it to keep an open mind. After a year of trying it in practice, I firmly believe that the previous way of doing it was better.

what led you to this? type safety from comptime-knowable state is a good thing

[andrewrk]

My comments on #12060 are still relevant, so check those out if you haven't already. To expand:

1. It's often, but not always, comptime-knowable whether the directory needs iterating.
2. The other directory opening flags have the same property: some subset of directory functionality is available based on their values, and they are also often but not always comptime-knowable. You can imagine that we don't want all of the following types:
   • Dir
   • IterableDir
   • AccessSubPathsDir
   • IterableAccessSubPathsDir
   • NoFollowDir
   • NoFollowIterableDir
   • NoFollowAccessSubPathsDir
   • NoFollowIterableAccessSubPathsDir
3. std.fs is missing an "open any" API #16738