* Refactor code. Move the C global function to a new SDWebImageCoderHelper class.
1. Create two method for animated image parse. Provide the way to allow animates on macOS
2. Create a new class called SDWebImageFrame to allow abstract usage for animated image
3. Fix EXIF orientation method will crash on iOS 7 because it’s a iOS 8 above API
* Change sd_imageLoopCount to retrieve GIF loop count for NSImage on macOS
* Adopt the refactor code, change our build-in coder with that coder helper method to reduce complexity
* Update the demo project on macOS to show animated WebP
- open the decoding/encoding procedures to the users
- switch from hardcoded decoding/encoding to pluginable decoders/encoders (builtin + user created)
- `SDWebImageCodersManager` is a singleton holding an array of `SDImageCoder` (protocol). Even though a singleton is not necesarily a good pattern, in this case it eliminates dealing with passing this array around
- uses a priority queue behind scenes, which means the latest added coders have priority.
- the priority is crucial when encoding/decoding something, we go through the list and ask each coder if they can handle the current data (see `canDecodeFromData:`, `canEncodeToFormat:`, `canIncrementallyDecodeFromData:`)
- each coder must conform to this protocol `SDImageCoder` describing all the required behavior for a coder
- we provide 3 built-in coders: `SDWebImageImageIOCoder` (for JPEG, PNG, TIFF), `SDWebImageGIFCoder` (for GIF), `SDWebImageWebPCoder` (for WebP and animated WebP)
- the user of SDWebImage can create custom coders by conforming to `SDImageCoder` and adding the coders to `SDWebImageCodersManager`. See `addCoder:` or `removeCoder:` or `coders` getter to get the array
- in order to preserve backwards compatibility, the UIImage categories were preserved, calling the new coders APIs described above