GPU object lifetime

This pull request was motivated by writing some new tests to ensure that GPU objects were released correctly. To that end, it contains the following changes:

- A refactoring of halide_printf such that it is implemented using a new function halide_print, which can be replaced in JITed code via set_custom_print. This is used by the new tests to ensure GPU object release functions are called as they are allocated.
- Two new tests for GPU object lifetime (static and JIT, both named gpu_object_lifetime). @jrprice, it would be great if you could review these to ensure they cover the issue you were seeing that you addressed with your previous pull request.
- Fixed a few GPU object leak bugs uncovered by the new tests.
- A major caveat: this pull request changes halide_printf for targets that I have not tested (iOS, Android, NaCl, Windows).

Regarding pull request #338, I actually found that in order to prevent leaks, I had to change the construction of the state back to the way it was. The current logic is this: the first time any module touches its global state variable, it is created and added to the global list, regardless of the construction of the module/program object itself. halide_release traverses the list, however, it does *not* remove the list nodes, only releases the objects contained in the list. This way, the next time a module re-creates its program object, the list simply doesn't change (only the contents of the relevant node is updated). This is slightly messy but I think it is reasonable, because the case in which the list grows (non-JIT), it only grows as you link new modules and not based on any runtime condition. @jrprice, any sanity checks on this would be much appreciated :)