[6.0] Update to use dynamic replacement for _NSNumberInitializer

[jmschonfeld]

Explanation: Removes a _typeByName lookup in a FoundationEssentials up-call that can result in confusion between the toolchain and local builds
Scope: Should only impact up-calls from FileManager in FoundationEssentials to initialize NSNumbers
Original PR: #5045
Risk: Low - small in scope and covered by unit tests
Testing: Testing done via swift-ci testing
Reviewer: @parkera

[jmschonfeld]

@swift-ci please test

[itingliu]

macOS CI failure looks unrelated to this PR but related to SwiftFoundation. Is that a known issue?

/Users/ec2-user/jenkins/workspace/swift-corelibs-foundation-PR-macOS/branch-release/6.0/swift-corelibs-xctest/Sources/XCTest/Public/XCTestMain.swift:21:23: error: no such module 'SwiftFoundation'
    @_exported import SwiftFoundation
                      ^

[jmschonfeld]

macOS CI failure looks unrelated to this PR but related to SwiftFoundation. Is that a known issue?

/Users/ec2-user/jenkins/workspace/swift-corelibs-foundation-PR-macOS/branch-release/6.0/swift-corelibs-xctest/Sources/XCTest/Public/XCTestMain.swift:21:23: error: no such module 'SwiftFoundation'
    @_exported import SwiftFoundation
                      ^

Yep, this project no longer builds for macOS so the macOS CI is no longer relevant and is expected to fail. It isn't disabled, but it's no longer marked as a required check so that we can merge even when it fails (SwiftFoundation used to be the old name of the SCL-F module on Darwin, but now that SCL-F doesn't build for Darwin even for testing purposes, the SwiftFoundation module doesn't exist so XCTest tests on Darwin can't find it - which is fine).