feat: add ability to configure the srcset width tolerance

[sherwinski]

This PR adds logic which will allow users to modify the width tolerance used when building srcset width pairs. More specifically, the width tolerance dictates the maximum allowable percent difference between entries in a srcset attribute. By default, this rate is set to 8 percent. Users can use this setting to fine tune how many srcset pairs they generate when calling Imgix::Path#to_srcset.

A user can now specify their own tolerance rate by passing a percent value to the keyword parameter width_tolerance. See the following example:

client = Imgix::Client.new(host: 'testing.imgix.net', include_library_param: false)
client.path('image.jpg').to_srcset(width_tolerance: 0.20)

In this case, the width_tolerance is set to 20 percent, which will be reflected in the difference between subsequent widths in a srcset pair:

https://testing.imgix.net/image.jpg?w=100 100w,
https://testing.imgix.net/image.jpg?w=140 140w,
https://testing.imgix.net/image.jpg?w=196 196w,
							...
https://testing.imgix.net/image.jpg?w=8192 8192w

[sherwinski]

@jayeb The sort of gotcha to all this is that we already calculate the default TARGET_WIDTHS when we instantiate a new Path object. But if the user opts for a different width tolerance, we end up recalculating a new set of widths on the fly. This is obviously going to cause us to perform repeated work whenever a user wants to specify their own tolerance, but in the grand scheme of things I still don't want to be calculating the widths every time we call to_srcset
I'm toying around with the idea of storing the custom widths locally to avoid recalculating on subsequent calls to to_srcset(width_tolerance:x), but might just hold off until all other srcset features are built out.

[jayeb]

The code all looks good. I'm not sure I agree with the decision to define this value as an integer, though. I would suggest we request the value as a unit scalar instead, so it better represents a percentage. This way we'd cut down on potential confusion where a user might think that the integer value they've provided represents an absolute value by which to scale widths, rather than a multiplier.