Shared cache loading fails to recognize CFString / NSString literals

[bdash]

Version and Platform (required):

• Binary Ninja Version: 4.2.6406-dev Personal (7c9db0b0)
• OS: macOS
• OS Version: 15.1
• CPU Architecture: arm64

Bug Description:
When opening a macOS dyld shared cache and loading a library that uses CFString or NSString literals, Binary Ninja often leaves references to them as opaque data_1e6b5cdb8 references. The data within the __cfstring section does not have its type set to struct __NSConstantString and is not renamed to a descriptive name.

These steps are done when loading an executable from the file system.

Steps To Reproduce:

1. Open /System/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e
2. Load AppKit.framework
3. Wait patiently
4. Search for _systemInformationRequested in the symbol list.

Expected Behavior:

1. The reference to the string literal should be named to provide some hint as to its contents (com.apple.SystemProfiler) rather than an opaque data_ reference.
2. The referenced data should have its type set to struct __NSConstantString.

For executables loaded from the file system rather than the shared cache, this reference typically would have been renamed to something like cfstr_com_apple_SystemProfiler.

Screenshots/Video Recording:
Reference from code:

Lack of type of data within __cfstring section:

Expected behavior (from an executable on disk, rather than a framework in the shared cache):

Binary:
See steps to reproduce.

[bdash]

Some combination of #6172, #6192, and #6198 fixes this.