Update Base SHA for Dangerfile checks

[ryan-mcneil]

Summary

• Before now, DANGER checks would always run against origin/master, so in the cases where a feature branch was the base branch, one would get unexpected results. For example if someone created a PR into a feature branch that changed 100 LOC, but the base branch already had 500+ changes, it would display a LOC error, despite it being in the acceptable range. This PR detects the BASE_SHA from the PR CI ENV.
• Note that these vars only exist in GITHUB ACTION runs, but perhaps not in other contexts, so I default to the original ways we were pulling the base/target, just in case
• I also removed the danger options --head=${{ github.sha }} --base=${{ github.event.pull_request.base.sha }} because they aren't actually being used (from what I can tell). It seems they were intending to solve the problem this PR is fixing, but never worked properly.

Testing done

• Here is a PR(feature/base branch) with an LOC change that's firing off warnings. From that I created a second branch/PR, only changing these ENV vars, and note that it is not detecting the large LOC change as it's looking at the change between it and the base branch/PR, not master.
• NOTE: Originally there was an issue and it was failing silently. Those issues are no longer present
• Here's another example branched off of this PR's branch. Note the single commit with the high LOC change and the action properly notifying

[rmtolmach]

reviewed in CoP meeting ✅

[LindseySaari]

Do you have to check ENV.fetch('GITHUB_HEAD_REF') for empty/nil?

[ryan-mcneil]

@LindseySaari I did that because if those vars ARE nil, it'll evaluate to "origin/", but I'd rather it default to 'git rev-parse --abbrev-ref HEAD'.chomp.freeze/origin/master in the case it is being ran outside of the GitHUB CI context (I believe it can be ran locally, per our convo yesterday).