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.