Slash commands should identify project by full path, even with there is an alias
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=386430)
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=386430)
</details>
<!--IssueSummary end-->
Currently, all slash commands that take a project (example: `/gitlab <project> issue show 1`) [identify the project by an _alias_](https://gitlab.com/gitlab-org/gitlab/-/blob/77190fc410ed0f6c7e8aed9616d825a8416d08e7/ee/app/services/slash_commands/global_slack_handler.rb#L54), rather than the project full path.
The alias can [be set from the GitLab for Slack integration form](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#create-a-project-alias-for-slack).
### Problem
Users must know the alias in order to use the slash command otherwise they experience the slash command as broken.
By default, the alias will be the same as the project's full path.
But when the alias has changed, the full path does not work in slash commands, which can be counterintuitive for users.
For example, this will error with a "project not found" response:
```
/gitlab gitlab-org/gitlab issue show 386430
```
Instead, we must use the configured alias:
```
/gitlab gitlab-ee issue show 386430
```
### Solution
In addition to supporting project _aliases_ in slash commands, also support regular project full paths where they are different.
For example, GitLab workspace users should be able to use either of these slash commands interchangeably:
```
/gitlab gitlab-org/gitlab issue show 386430
/gitlab gitlab-ee issue show 386430
```
### Availability & Testing
This behavior would seem to result in a change to [SlashCommands::GlobalSlackHandler#find_slack_integration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/slash_commands/global_slack_handler.rb#L50)
Let's add/modify tests to https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/spec/services/slash_commands/global_slack_handler_spec.rb around the following scenarios
```ruby
context "with existing project" do
context "with alias" do
it "handles command using alias" {}
it "handles command using project path" {}
end
it "handles command using project path" {}
it "raises error using missing/incorrect alias" {}
end
```
<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change
See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance.
Quad Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning
Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/#test-planning -->
issue