Remove accidental dependency on NIOFileSystem (#298)

swift-nio's public export of NIOFileSystem was removed in 2.86.1:
apple/swift-nio#3370

NIOFileSystem was not yet supposed to be public, but _NIOFileSystem
depended on it as a public import. This made it possible for
`containerization` to see the `NIOFileSystem` package by accident.

Replacing the use of `NIOFileSystem` by `_NIOFileSystem`, as used
elsewhere, fixes the problem.

## Why does CI currently pass?

The change in `swift-nio` does not currently cause `containerization`'s
CI to fail because `Package.resolved` pins `swift-nio` to 2.83.0, before
the change was made. New versions of upstream dependencies will not be
tested until `Package.resolved` is explicitly updated.

When containerization is built as a dependency of a end-user project,
its `Package.resolved` file is ignored. Instead, the dependency
constraints from containerization's Package.swift file are combined with
those of the project and any other library dependencies, so SwiftPM or
Xcode can find a set of mutually compatible packages. This can lead to
new versions of containerization's upstream dependencies being used,
even though those versions have never been tested in CI.

The build failure can be demonstrated by creating a new package which
depends on `containerization` but does not constrain package versions:
```
    % swift package init --type executable
    Creating executable package: test
    Creating Package.swift
    Creating Sources
    Creating Sources/test/test.swift
    % cat > Package.swift <<EOF
    heredoc> // swift-tools-version: 6.2
    // The swift-tools-version declares the minimum version of Swift required to build this package.

    import PackageDescription

    let package = Package(
        name: "test",
        platforms: [
            .macOS(.v26),
        ],
        dependencies: [
            .package(url: "https://github.com/apple/containerization", from: "0.7.2"),

        ],
        targets: [
            // Targets are the basic building blocks of a package, defining a module or a test suite.
            // Targets can depend on other targets in this package and products from dependencies.
            .executableTarget(
                name: "test",
                dependencies: [
                    .product(name: "Containerization", package: "containerization"),
                ]
            ),
        ]
    )
    EOF
    % swift build
    ...
    /private/tmp/test/.build/checkouts/containerization/Sources/ContainerizationOCI/Client/RegistryClient+Fetch.swift:25:8: error: no such module 'NIOFileSystem'
     23 |
     24 | #if os(macOS)
     25 | import NIOFileSystem
        |        `- error: no such module 'NIOFileSystem'
     26 | #endif
     27 |
```

Author: euanh

Sources/ContainerizationOCI/Client/RegistryClient+Fetch.swift

@@ -22,7 +22,7 @@ import Foundation
 import NIOFoundationCompat
 
 #if os(macOS)
-import NIOFileSystem
+import _NIOFileSystem
 #endif
 
 extension RegistryClient {
@@ -170,7 +170,7 @@ extension RegistryClient {
     public func fetchBlob(name: String, descriptor: Descriptor, into file: URL, progress: ProgressHandler?) async throws -> (Int64, SHA256Digest) {
         var hasher = SHA256()
         var received: Int64 = 0
-        let fs = NIOFileSystem.FileSystem.shared
+        let fs = _NIOFileSystem.FileSystem.shared
         let handle = try await fs.openFile(forWritingAt: FilePath(file.absolutePath()), options: .newFile(replaceExisting: true))
         var writer = handle.bufferedWriter()
         do {