Switch to a more robust solution that string matching for Catalyst error humanization

[yondonfu]

#101 and #104 implemented humanized errors for certain internal errors. But, the approach is pretty fragile as it is based on string matching so if the error messages downstream change the logic here could break. We should consider a better way to categorize and transform these internal errors into humanized versions. For example, if there are special error types we could check if an error is of that type and determine the humanized error message to return i.e. ErrInaccessibleFile -> "file could not be accessed" and ErrInaccessibleFile could be used to wrap different error messages i.e. 504 Gateway Timeout, giving up after X attempts, etc.

This is scoped for Catalyst error humanization, but the approach here might be useful for other forms of error humanization as well.

Additionally, the string matching approach exposes task-runner to the internal details of Catalyst (i.e. MediaConvert). A better approach would hide those implementation details from task-runner.