Add UserError

[aeisenberg]

This commit adds a UserError class that should be thrown when the
cause of an error is fundamentally from user configuration.

When sending status reports, avoid sending a failure for UserErrors.
This will prevent our diagnostics from pinging us for errors outside of
our control.

This particular PR adds two cases where we use user-error instead of failure:

1. When the action is too old and cannot support the version of the CLI being used.
2. When a user calls the init action twice in one workflow.

We can add more cases as we see fit.

Questions for reviewers:

1. Is it ok to add a new kind of key (user-error) to our status reports?
2. I'm not happy with using text matching and regex to determine if the error is from the user. Is there a better way? We may need to also make changes to the CLI to add some sort of error code or other way to identify errors.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[aeisenberg]

OK...Looks like there may need to be a server-side change as well. Here is an attempt to send a user-error report. It fails with:

user-error is not a member of ["success", "failure", "starting", "aborted"].

Alternatively, we could send aborted and avoid changing the server, but the semantics isn't right.

[edoardopirovano]

All seems good to me. You'll want to hold off merging till my PR doing the server-side changes is merged, however.

[edoardopirovano]

Server-side changes are done. I'm going to go ahead and merge this.

[edoardopirovano]

Confirmed a test run looks good: https://github.com/edoardopirovano/actions-test2/runs/5302594964

I can also find the test run in Splunk and it's correctly tagged with user-error.