memory leak

[Bobscorn]

In the algorithm.c file, fill_chunkmap leaves 3 chunkmaps un-free-d.
fill_chunkmap is given an input chunkmap as shown
void fill_chunkmap(chunkmap* map, vectorize_options* options) {
and then creates 3 more (such that each quadrant has it's own chunkmap it can write to without requiring a mutex).
This is shown here:

chunkmap* map2 = generate_chunkmap(map->input, *options);
Quadrant quadrant2 = {"top-right", map2, options, NEGATIVE, POSITIVE};
quadrant2.bounds.startingX = middle_width;
quadrant2.bounds.startingY = 0;
quadrant2.bounds.endingX = map->map_width;
quadrant2.bounds.endingY = middle_height; 

chunkmap* map3 = generate_chunkmap(map->input, *options);
Quadrant quadrant3 = {"bottom-left", map3, options, POSITIVE, NEGATIVE};
quadrant3.bounds.startingX = 0;
quadrant3.bounds.startingY = middle_height;
quadrant3.bounds.endingX = middle_width;
quadrant3.bounds.endingY = map->map_height;

chunkmap* map4 = generate_chunkmap(map->input, *options);
...

However the 3 newly created chunkmaps are never freed.
This doesn't matter for chunkshapes, as the 3 chunkmaps' chunkshapes are appended onto the input chunkmap, however the pixelchunks are not moved to the input chunkmap, which leaves the equivalent of 3 images worth of data leaking every call.

However again, simpling freeing these 3 maps with free_chunkmap would cause the shapes that used to be in the 3 chunkmaps to point to now freed pixelchunks, thereby causing access violations in the next steps of vectorization.

[DoubleCouponDay]

we also need to take image structs by reference when creating new chunkmaps in a threading context.

[DoubleCouponDay]

related to #55