Support representation of Swift string literals

Version and Platform (required):

• Binary Ninja Version: 3.3.4069-dev (Build ID e4643f69)
• OS: macOS
• OS Version: 13.1
• CPU Architecture: M1

Bug Description:
Swift (at least on arm64 macOS) has an odd way of referring to string literals. Here is the original assembly produced by swiftc:

	adrp	x8, l_.str@PAGE
	add	x8, x8, l_.str@PAGEOFF
	sub	x8, x8, #32
	orr	x1, x8, #0x8000000000000000

Or as disassembled by Binary Ninja (the string ended up at 0x100103f70):

100003f54  08080090   adrp    x8, 0x100103000
100003f58  08c13d91   add     x8, x8, #0xf70
100003f5c  088100d1   sub     x8, x8, #0x20
100003f60  010141b2   orr     x1, x8, #0x8000000000000000  {0x8000000100103f50}

The problem is that Binary Ninja doesn't create an xref to 0x100103f70, presumably because it emulates the whole sequence of operations and ends up with 0x8000000100103f50.

Using the decompiler for xrefs is often helpful, but here it's counterproductive compared to a more naive approach of looking for adrp/add pairs.

Ideally, Binary Ninja would be able to identify these references.

Steps To Reproduce:

Disassemble this test binary and go to the __cstring section. Note that there is no reference to the string.

This corresponds to the following source code:

public func get_string() -> String {
    return "this is a long string so it doesn't get small-string optimized"
}

Note that I had to add a bunch of padding between the code and the string. Without this, the linker will replace the adrp/add pair with adr/nop, and Binary Ninja does identify the reference in that case.

Additional Information:
There is nothing meaningful located 0x20 bytes before the string (the string is at the very start of the section), so the subtraction of 0x20 is just part of some pointer encoding scheme, along with the OR of 0x8000000000000000. Not sure about the details of this scheme.