Refactored polygon functions to unify logic

The functions `polygon8`, `polygon32` and `polygon32rgba` all have exactly
the same logic in code, only changes the hline function called inside.

Now all the logic is contained in `polygon_generic` which gets a
function pointer to the hline handler, so there is no duplicated code
anymore.
Implementation of rounds around zero

The rounds used in the library are towards positive/negative infinity.
Since we're in a cartesian plane, rounds around zero are much more
convenient, so we can use positive and negative values with consistent
results.
Rewrite of the polygon_generic function

The (previously refactored) polygon_generic function didn't draw
consistent polygons (equilateral polygons were not equilateral nor
symmetrical).

The most notable changes are:
  * The horizontal edges are searched for when finding the polygon
    boundaries, drawn and discarded from the edge list used to detect
    intersections.
  * The intersections are now checked and calculated from the current value
    of the scan line (ymin) instead of in the middle (ymin + 0.5).
  * Because the change in the scan line behavior, we should duplicate
    the intersections in the maximum Y value of an edge or there will be
    draw errors with concave and complex polygons.
  * The rounds of the X coordinates in the hline function calls are
    switched to draw the inner pixels.
  * Removed the ugly micro-optimization of qsort at the end.

This implementation of the scan line algorithm may not be technically
correct, it's not optimized and it have problems with some edge cases,
like a wide line from (x0, y) to (x1, y + 1), therefore it should be
reviewed in the future.
Rewrite of the ImagingDrawWideLine function

The previous version of the function didn't generate correct wide lines
of even width.

The most notable changes are:
  * Make variable names far more descriptive about the process.
  * Corrected the width calculation; we should deduct one pixel from the
    width because the pixels at the center of the line doesn't count for
    the triangles.
  * Now we calculate *two* ratios, one for left/top displacement (dxmin)
    and one for right/bottom (dxmax), this fix the behavior with lines
    of even width.

It can probably be optimized.
Oops, fixed typo in comments
Added base method and constants to test_imagedraw

The method `create_base_image_draw` will be used in all the new draw
tests.
Added test for a simple square
Added test for a simple right triangle

The diagonals of the right angled edges must be perfect and the bottom
vertice should be drawn.
Added test for horizontal lines

Notice that the expansion of the line width depends on the order of the
points:
  * If the bigger axis value is provided as the *second* point the line
    expand first to the *positive* side of the axis.
  * If the bigger axis value is provided as the *first* point the line
    expand first to the *negative* side of the axis.
  * If the line's width is odd this doesn't matter, as the line will
    expand the same amount to both sides.

This behavior should be consistent in both horizontal and vertical lines.
Added test for vertical lines.

The behavior is consistent with horizontal lines, see previous commit
for details.
Added missing xx pointer check
Added missing free when xx fail
Oops, added missing ';'

Now writing in the wall "don't push before compile" 100 times.
Added descriptive errors to imagedraw tests
Added some oblique 45º lines tests

Only the oblique 3 pixels wide lines are defined:
* The oblique 2 pixels wide lines are somewhat hard to define.
* To define the oblique lines wider than 3 pixels we neet to define
  first how the oblique lines should expand their width (realistic or
  exact).
Added tests of hor/ver lines 101px wide

These tests should guarantee that the proportion of the width is
maintained with a margin of error < 1%.
Added tests for lines with 1px slope

This tests are designed to guarantee that the wide lines behave exactly
like normal lines drawn with the Bresenham's algorithm.
This tests are somewhat subjective since this is non-defined behavior,
but I think that mimic the Bresenham's algorithm is reliable enough.

Currently the horizontal version of this test **fail**.
Removed non-ASCII character from messages
Merge from master
Merge branch 'master' into terseus_imagedraw