Platform API Refactor

[rssor]

Platform objects are better suited to take over certain roles, such as:

• Global/system register lists from Architectures (consider toolchain dependent use of registers like r2/r30 on ppc)
• TypeLibrary resolution from BinaryView init — right now dynamic linker behavior has to be emulated in the BinaryView implementation directly, but it makes more sense to parcel this out to the appropriate Platform to enable the same ELF BinaryView implementation to be shared across Platforms with different dynamic linker behavior

We also need additional expressiveness in the form of:

• Allowing global/system registers to be assigned type information (consider windows, where fs and gs will be used to access very different structures between usermode/kernelmode, meaning we need to have different platforms not only for usermode vs kernelmode code, but also different versions of NT)
• Registration of callbacks that select Platforms for BinaryViewTypes during init to enable this more specific platform identification, particularly by plugins (allowing us to deprecate BNRegisterArchitectureForViewType/BNGetArchitectureForViewType and its BNPlatform variants)
• The ability for Platforms to be used to interpret constant loads for the purposes of dataflow loads with read-only semantics. This allows handling of arbitrary endianess as in PDP-endian (or custom endianness) support in core API #1934, as well as properly rendering datavars on certain architecture/toolchain combinations. As an example, some SH4 toolchains will store doubles in 2 32-bit chunks that need to be swapped if you want to implement them as a single 8 byte load. While this can be handled in a lifter just fine, it does mean that the datavars won’t render correctly. Shifting the responsibility of interpreting bytes on behalf of rendering/dataflow to the Platform object allows this to be done transparently.

[whitequark]

• The ability for Platforms to be used to interpret constant loads for the purposes of dataflow loads with read-only semantics. This allows handling of arbitrary endianess as in PDP-endian (or custom endianness) support in core API #1934, as well as properly rendering datavars on certain architecture/toolchain combinations.

Another motivation for this feature is rendering uleb128 fields, e.g. in Dalvik bytecode, or perhaps in DWARF.

[yrp604]

One thing to explicitly highlight -- this ticket would allow much easier identification main in Windows binaries. This sounds trivial, but is a reliably annoying papercut that I hit frequently...

[plafosse]

This would allow us to disable linearsweep if not relevant for a given BinaryView. For instance LC_FUNCTION_STARTS in MachO and binaries linked with CFG/XFG info.