* Fix recoverable [U]Int128 division-by-zero
This patch fixes the division-by-zero case in the following methods:
- `Int128/dividedReportingOverflow(by:)`
- `Int128/remainderReportingOverflow(dividingBy:)`
- `UInt128/dividedReportingOverflow(by:)`
- `UInt128/remainderReportingOverflow(dividingBy:)`
* Add preconditions to trapping [U]Int128 division methods.
* Make consistent use of `_slowPath(_:)`.
Jumping on the `_slowPath(_:)` bandwagon like all other integer types.
* Copy existing UInt128 division comments to division operators.
* Add a comment about signed remainder overflow semantics as requested.
I have paraphrased @stephentyrone's and @xwu's review comments to the best of my ability.
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
