Added catch-all for permission errors.

[mitchell-as]

DX-2646 We don't report access denied errors to rollbar

We don't want to report these to rollbar.

Note: I chose not to centralize reporting inside the fileutils package because there are dozens of functions in there that would have to be changed, and there are also other files that use os-level functions that may return these types of errors (such as os.OpenFile() used by the projectfile package). I figured the best way to approach this was to have a catch-all at the bottom of the error funnel rather than having callers explicitly check for permission issues (similar to top-level rationalize.ErrNoProject handling) and crafting appropriate error messages.

Further note: based on the generality of this solution, it's impossible to provide a truly helpful message (such as which file/folder had a permission issue) without implementing full-blown user-facing errors and types/structs. I figured that was out of scope for this small-ish task at hand.

[mitchell-as]

Test failures are not due to this PR.

[Naatan]

I'm worried that this is going to silence errors that aren't user input. There is no guarantee that the path in question was not writable due to the user giving us something invalid, or due to a bug we introduced.

Seeing as that's the case, I don't think we can solve this problem with a catch-all. We need to catch the individual cases, because only then can we correctly assert the cause to be user input.

I'm putting it on request changes, but really I would propose we abandon this story.

[mitchell-as]

I agree with you. We should handle these errors on a case-by-case basis as they come in from Rollbar. After all, that's what it's for...