Task file upload module

Moved the task file association from tasks to task_responses. Abstracted to the code out to it's own task module.
Yeah, it's actually been that way, although they used to be on the task_section and task classes before we moved the task_files association. I've thought about this too. If it were just a hash of file options, it would be easy to abstract elsewhere to a central place, however, this actually defines the possible values for the specific field "file_type" for both tables and has to be in each class in order for the enum helper methods to also work. That then begs the question, do we need to have both classes contain that file_type field? Maybe not. I think we did it primarily to keep query chains from getting too hairy. The Task Section defines that particular section and module to be used within a task, and a potential file type. This is a child to a Task Definition. These classes simply define the tasks. When the user submits task data, it stores down into Tasks, Task Responses, and Task Files (which is associated to Task Responses). So, the enum for "file_type" is also in Task Responses so we don't have to do something like TaskResponse.section.file_type every time we want to get the type for the attached file. If you'd like me to put a little time simplifying it down to having that field in one table, instead of two, I'm okay with that. Looking at the code, I think the time and the query impact would me minimal. Thoughts?