Make Danger work on PRs from forks

[Samasaur1]

I'm also still seeing

Response: {
[38](https://github.com/Samasaur1/DiceKit/runs/6732668468?check_suite_focus=true#step:4:39)
  "message": "Resource not accessible by integration",
[39](https://github.com/Samasaur1/DiceKit/runs/6732668468?check_suite_focus=true#step:4:40)
  "documentation_url": "https://docs.github.com/rest/reference/users#get-the-authenticated-user"
[40](https://github.com/Samasaur1/DiceKit/runs/6732668468?check_suite_focus=true#step:4:41)
}

in the Danger logs, which I believe is due to Danger running in the PR and therefore the token not having write access. For now, it's able to comment because the PR isn't coming from a fork, but I probably want to change this to use the pull_request_target event (and use the Dangerfile from my repo, so that the token can't be exploited that way).. See here: https://github.community/t/github-actions-are-severely-limited-on-prs/18179/20

Originally posted by @Samasaur1 in #90 (comment)

[Samasaur1]

This isn't an immediate problem, as it doesn't stop me from working on this, but it would be nice to get it set up before anyone else tries to contribute, so that I don't have to scramble to set it up

[Samasaur1]

The idea as I currently have it is that we use the pull_request_target event (which gives the built-in GitHub token write access, since it runs on the base, not the merge). This runs my workflow file, which is why it is safe for it to have write access. In the workflow file, I can have it checkout the merge (incorporating their code, while still running my safe workflow), and then run Danger.

The only security implication that I'm aware of when doing this is that Danger runs the local Dangerfile, which would be a problem if I allowed it to run modified Dangerfiles while authenticated. I believe I can circumvent this by telling Danger to use the Dangerfile from the master branch, which means that the only limitation here would be that the Dangerfile cannot be modified in PRs from forks and then run on that PR (which isn't really a limitation, but the desired behavior)