[IDNA] Documentation improvements, performance improvements

[karwa]

Before

name                                  time          std        iterations warmup           
-------------------------------------------------------------------------------------------
Constructor.HTTP.AverageURLs           24707.000 ns ±  17.66 %      53628  266289080.000 ns
Constructor.HTTP.AverageURLs.filtered  37439.000 ns ±  27.44 %      33427  416324500.000 ns
Constructor.HTTP.IDNA                 141071.000 ns ±  23.49 %       9138 1548975540.000 ns

After

name                                  time          std        iterations warmup           
-------------------------------------------------------------------------------------------
Constructor.HTTP.AverageURLs           23391.000 ns ±  24.68 %      61023  238289616.000 ns
Constructor.HTTP.AverageURLs.filtered  38563.000 ns ±  26.68 %      32004  431694166.000 ns
Constructor.HTTP.IDNA                 110999.500 ns ±  23.30 %      11272 1268018770.000 ns

The biggest issue is still the NFC normalization, which comes from Foundation and requires bridging, etc. Using the standard library NFC instead is way faster:

xcrun -toolchain swift swift build -c release -Xswiftc -DWEBURL_IDNA_USE_STDLIB_NFC                                                                                              
<plus some rpath fiddling with install_name_tool so it actually uses the toolchain stdlib>

name                                  time         std        iterations warmup          
-----------------------------------------------------------------------------------------
Constructor.HTTP.AverageURLs          24325.000 ns ±  27.30 %      54222 237479378.000 ns
Constructor.HTTP.AverageURLs.filtered 39292.000 ns ±  25.89 %      32053 439869002.000 ns
Constructor.HTTP.IDNA                 71475.000 ns ±  23.93 %      18097 788458819.000 ns

But even that could be much better. We're still buffering everything in a string, and profiling shows that is by far the biggest performance hit. That's just because of how the stdlib SPI happens to be exposed; it could offer something far more efficient and help us cut that out (also, isNFC could be way faster than we're doing it here).

So yeah - better NFC normalization APIs are what we need to really make a significant dent.