SSL2 shouldn't ever be enabled, and it isn't enabled in Fiddler unless you go out of the way to shoot yourself in the foot.
If you've properly configured your iOS device to trust Fiddler's root certificate, then HTTPS interception will work properly in clients except where certificate pinning is in use. While Certificate Pinning in Chrome won't matter on the Desktop, on iOS they ignore the Trusted Certificates store and as a consequence Fiddler interception will not work. But most sites and apps do not use pinning. If a site or app uses pinning, there's no workaround short of jailbreaking the device. This isn't a limitation unique to Fiddler-- every HTTPS-decrypting proxy has exactly the same limitation.
This message: HTTPS handshake to github.com failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm
...indicates that your Fiddler instance is not offering the server a TLS version that it is willing to accept. You should generally use SSL3; TLS1.0; TLS1.1; TLS1.2
This message: Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
... is harmless.
This message: !SecureClientPipeDirect failed: System.IO.IOException Authentication failed because the remote party has closed the transport stream. on pipe to (CN=init.itunes.apple.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)
... indicates that the client refused to send a request because it didn't like the certificate it received. This appears to be a request from iTunes and we do know that iTunes uses Certificate Pinning when talking to the Apple store on the web.
You didn't say which version of Windows you're using, but that does impact what ciphers are available.