Refactored Markers to use dynamic memory response

Switched net.c's stringToReturn to be a char** in order to pass the
string into the function and be able to modify and resize it. Updated
markers to handle and test this.

Now able to bump the marker limit up again to 100 becuase we can handle
creating the JSON without truncating the result.

Updated marker spec tests to handle this correctly.

Note that the define for the err label and return had to be swapped in
the marker controller in order to handle and test this. However we shall
soon update the other controllers to handle this as well and then that
 #undef-ing will not be neccesary.
Updated stringToReturn type to all controllers.

md5sum a.out
5ca95f3e7a6d9660afa219159da1ff78  a.out

Modified char * -> char ** for all controllers so that if we need to
update them to swap memory in order to support a non-truncated response,
we can do so. Things like GET on resources that return lists of JSON objects
need to be updated to handle this.
Refactor GET Comments to use dynamic memory

md5sum a.out
0aaa06166c1ccd706e41f8fdff1ac3aa  a.out

Since the GET endpoint of comments is a list of indeterminant size we
need to use dynamic memory instead of the stack space we were alloting
before. This has been done and tested to work by lowering the request
size to a small number and ensuring that the memory was swapped up for
higher space.
Heatmap GET Update. Marker GET Update.

md5sum a.out
0311442d15a66548fa2d5c5289152660  a.out

Updated Heatmap to use dynamically allocated memory for it's listing.
This way the requests are not truncated in anyway. Did the same for
markers GET.
Refactored reports to use dynamic memory for Lists

md5sum a.out
d99cf22ccc5483a45f63d1d412369cc5  a.out

GET endpoint of reports (the paginated, not the single) now uses memory
allocated at runtime in order to handle reports of long lengths. Works
well.
Merge branch 'response-refactor'