sRGB⇔linear sRGB conversion performance improvements

The phone time is cut in half again!

• Converted the srgb:: functions to use look-up tables instead of costly floating point operations + pow. Due to having to round unpremultiplied pixel values to use the lookup table, this very slightly changed the results of some filter tests.
• This dropped the phone from 16 seconds to 11 seconds.
• This dropped rsvg-bench -p 1 -r 100 tests/fixtures/reftests/svg1.1/filters-*.svg from 51 seconds to 38 seconds.
• Replaced alpha_only in SharedImageSurface with a more general SurfaceType which indicates if the surface is sRGB, linear sRGB or alpha-only. I then changed the filter code to only convert between the color spaces when necessary. This is very important because in the common case a bunch of filter primitives will have the same color-interpolation-filters, and there's no need to convert to linear sRGB, then to sRGB and then back to linear sRGB between every two primitives.
• This dropped the phone from 11 seconds to 8 seconds.
• Didn't really affect filters-*.svg, probably because when there are filter chains they operate on tiny surfaces.
• Switched from rulinalg to nalgebra for matrix and vector operations. nalgebra is much more widely used (165k vs. 10k), is actively maintained and most importantly has both dynamic and static stack-based types. This allowed me to get rid of the allocations in the lighting code.
• Phone: 8 seconds -> 7.6 seconds.
• Didn't affect filters-*.svg.

This time I used callgrind + KCachegrind for visualization (my first time using callgrind). KCachegrind provides a very good overview of things and includes a number of different ways of visualizing them, including a call graph, a callee map and a source code view with performance marks. It also seems to provide better call graph info than perf + flamegraph.

Either way, here's the latest flamegraph: