Unsupported states crash Progress reporting

Currently, there seems to be two task states that will slip past the currently accounted for states in `Progress.get_info()`:
1. IGNORED
- HTTP: When used with a progress recorder's `stop_task()` as demonstrated in #4, `stop_task()` will function as expected. However, if `stop_task()` is not used, upon finishing the task, the result backend will still have the `PROGRESS` state, meaning the client-side javascript will continue to request the same resource over and over again until the page is closed.
- WS: As with HTTP, when used with `stop_task()`, it works fine. Without, the progress bar will get to max but never complete, and as the task has already technically finished, no further updates will be sent. The JS will be left to sit, waiting for a response that will never come, and will wait until the server times out the connection.
2. RETRY (as noted by #53)
- HTTP: Once the retry exception is thrown, the progress request will try to serialize the error and fail, returning a 500 error for the http request and killing the bar.
- WS: Once the retry exception is thrown, the progress request will try to serialize the error and fail, forcing the post-run handler to retry sending the error over and over until the retried task is successful.

Both situations pose an interesting challenge on how they'll be handled. For `IGNORED`, it may be worth revisiting `stop_task()`'s implementation and offering a possibly better solution than what is currently being used. Successfully fixing the handling for `RETRY` could eventually pave the way for #13 to get some as love as well. Thoughts on this would be greatly appreciated!