Allow overriding context (issue number) for comment and checkmark

### The use case you're trying to solve

It's a bad idea from security perspective to build the project and deploy preview from the same action that has write access to the repo, as malicious PR can get access to secrets like Firebase token. See https://securitylab.github.com/advisories/GHSL-2020-274-v8-v8-dev-workflow/ where we ran into this issue with v8.dev in the past as well as https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ for an extended write-up about this issue and ways to prevent it.

The recommended approach is to instead split building the project into a regular `pull_request` action that doesn't have write access to the repo, and have a separate manually triggered action that does only the deploy of the artifacts, and then use Actions artifacts to share the built files from one action to another.

You can see how we did it in the end in v8.dev here: https://github.com/v8/v8.dev/tree/main/.github/workflows

This works well, but the only problem is that the second action doesn't have the associated PR number anymore, so `action-hosting-deploy` is unable to post the comment or create Github checks as it currently uses `.issue.number` to determine an issue on which to post the comment: https://github.com/FirebaseExtended/action-hosting-deploy/blob/0f248036885ae672f78587669fa2923f0ef6cac2/src/postOrUpdateComment.ts#L74

Instead, we have to use a 3rd-party action to post or update a comment ourselves: https://github.com/v8/v8.dev/blob/a10e57b73b76ca6ea424058730b73bde5b41c962/.github/workflows/pr-preview.yml#L33-L36

This is not too bad, but restoring native functionality of `action-hosting-deploy` would be preferable.

### Change to the action that would solve that use case

Allow setting `issue-number` (and potentially `repo`) as action inputs for `action-hosting-deploy`, and, when those are set, use them instead of `context.issue.number` to post comments and checks.

### Other considerations