Add handling of `origin` to method `point_to_same_commit?`

[iangmaia]

What does it do?

Starting from the comment https://github.com/wordpress-mobile/release-toolkit/pull/587#discussion_r1741270988, I realized we already have checks and logic in place to make sure the head and base branches start with release/ and that it would make more sense to have any logic related to the point_to_same_commit? check locally vs. on remote in the method itself, so this PR updates point_to_same_commit? for that.

Checklist before requesting a review

• [x] Run bundle exec rubocop to test for code style violations and recommendations
• [x] Add Unit Tests (aka specs/*_spec.rb) if applicable
• [x] Run bundle exec rspec to run the whole test suite and ensure all your tests pass
• [x] Make sure you added an entry in the CHANGELOG.md file to describe your changes under the appropriate existing ### subsection of the existing ## Trunk section.
• [x] If applicable, add an entry in the MIGRATION.md file to describe how the changes will affect the migration from the previous major version and what the clients will need to change and consider.

[iangmaia]

Interesting. CI reports failures in tests that are stubbing point_to_same_commit? (a good case for avoiding stubs, however that's easier said than done in this repo...).

Example:

FastlaneCore::Helper::GitHelper received :point_to_same_commit? with unexpected arguments
  | expected: ("origin/release/30.6", "origin/release/30.7")
  | got: ("trunk", "release/30.7")
  | Please stub a default value first if message might be received with other args as well.

True, I should've updated stub_expected_pull_requests with:

- allow(Fastlane::Helper::GitHelper).to receive(:point_to_same_commit?).with("origin/#{target_branch}", "origin/#{source_branch}").and_return(point_to_same_commit)
+ allow(Fastlane::Helper::GitHelper).to receive(:point_to_same_commit?).with(target_branch, source_branch).and_return(point_to_same_commit)

It should be fixed now.