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

https://github.com/livepeer/task-runner/pull/101 and https://github.com/livepeer/task-runner/pull/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.

Start by reviewing pull requests 101 and 104 to locate the current Catalyst error humanization and its string matching. Define how internal errors such as ErrInaccessibleFile should be categorized without exposing downstream implementation details, then verify that the resulting humanized messages remain stable across the listed underlying error messages.