Disable the edit button, instead of not rendering it

What does this MR do and why?

1. WebIdeLink gets a new prop that allows to have a custom tooltip for more specific scenarios.
2. Edit button on blob pages renders by default, without waiting for blobInfo query results. It's first in a disabled state, then after the data is fetched we determine if it can be enabled. If not, we add a tooltip specifying the reason why the button can not be used.

While preparing for this MR, I specified six scenarios why editing may not be possible. They are not all covered by these changes. Here's why:

1. The project is archived ✅
2. The file is stored externally (e.g., LFS) ✅
3. The user doesn't have permission to edit the file ❌ - this scenario is covered by the logic for showing a fork suggestion. The button is enabled, but editing happens in a fork of a project.
4. The user is not viewing the latest commit on a branch ❌ - this scenario is covered by the logic for showing a fork suggestion. For single file editor, the change happens in the fork of a project. WebIDE is able to handle such edit, so user is directed to the editor within that project.
5. The repository is in a read-only state ❌ - this scenario is covered by the logic for showing a fork suggestion. Backend will neither return ideEditPath nor editBlobPath, and the fork suggestion will be triggered.
6. The file is a binary file that can't be edited ❌ - this scenario is covered by the WebIdeLink component. :show-edit-button="!isBinaryFileType" hides the edit with a single file editor from the dropdown, while the edit with WebIDE is still possible.

Additionally, the button is disabled when there are query errors.

In the end, there were no new constraints introduced. I only moved the previous logic around v-if and :disabled prop on WebIdeLink, so that the button is always rendered, but disabled for all these cases with appropriate context.

References

Screenshots or screen recordings

Context	Before	After
LFS
archived project
query error

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

The easiest way to validate LFS, is to run a feature test in debug mode:

1. Apply this diff

diff --git a/spec/features/projects/blobs/blob_show_spec.rb b/spec/features/projects/blobs/blob_show_spec.rb
index 248c7afa07b3..cd05ada553f9 100644
--- a/spec/features/projects/blobs/blob_show_spec.rb
+++ b/spec/features/projects/blobs/blob_show_spec.rb
@@ -264,6 +264,7 @@ def switch_ref_to(ref_name)
       end
 
       it 'displays an error' do
+        live_debug
         aggregate_failures do
           # hides the simple viewer
           expect(page).not_to have_selector('.blob-viewer[data-type="simple"]')

2. Run bin/rspec spec/features/projects/blobs/blob_show_spec.rb and check Edit button when the test case opens in your browser.
3. Go to any project on your GDK and archive it. Then go to any file in that archive project and check Edit button.
4. Impersonate one of the users on your GDK and go to a project where they have a role Guest. Then go to any file in that archive project and check Edit button.
5. To emulate query errors, you can apply this patch:

diff --git a/app/assets/javascripts/repository/components/header_area/blob_controls.vue b/app/assets/javascripts/repository/components/header_area/blob_controls.vue
index b280d3ec3fee..fe0f54e0593b 100644
--- a/app/assets/javascripts/repository/components/header_area/blob_controls.vue
+++ b/app/assets/javascripts/repository/components/header_area/blob_controls.vue
@@ -132,7 +132,7 @@ export default {
       currentUser: {},
       gitpodEnabled: false,
       isForkSuggestionModalVisible: false,
-      hasProjectQueryErrors: false,
+      hasProjectQueryErrors: true,
     };
   },
   computed: {

6. Refresh the blob page and verify the Edit button in the disabled state with appropriate tooltip.

Related to #537448 (closed)