Add output variable so workflows can detect linter problems

[markphip]

This adds an output variable named problems_detected that will be set to true if one or more of the linters find problems OR if an autofix event creates and pushes a code change back to the pull request. The README.md was also updated to document this variable and provide an example of its usage. This would close issue #60

[ocean90]

Thank you for the detailed pull request! I like the idea of using output variables for this but I'm wondering if we should provide one for each linter since it's possible to run multiple linters in one step. Just like the input variable we could prefix it with the later name, for example black_problems_detected or eslint_problems_detected. Thoughts?

Once I get the tests working again and #91 is merged, we can also use @actions/core.

[markphip]

I have started using this and have already thought that at minimum there should be separate flags for autofix and linter problems. I would not be at all opposed to one flag per linter. I will say that I have already exceeded my capabilities here as once I get past copy and pasting some Javascript I am out of my element. So hopefully someone else can pick this up and turn it into a worthy feature to include. The basic concept is working well for m though.

[ocean90]

@markphip Do you think this is still helpful now that we have continue_on_error #124?

[markphip]

I have not tried it yet, but this would have met my needs. I like that it is simpler and addresses what most people probably want. My solution was mainly because I did not think you wanted it to work this way (or I did not think of it). There is some potential value in the approach I took to handle more complex scenarios ... but I will likely abandon what I did and switch to this at some point because I really just wanted to end the job when there were errors.

[ocean90]

Yeah, it's actually a decision against the initial design of the action. But since GitHub currently doesn't provide an easy way to take action on the result of check runs I decided to go with continue_on_error for an improved developer experience.