Added suffix and path filters for quickopen

[revaraver]

Hello,
I’ve become completely reliant on this plugin during my time using Godot.

The reason for this PR is that I foolishly added over 30,000 png and svg assets into my assets folder.
As a result, whenever I use Quick Open, unless I select a filter for scenes or GDScript files, every single keystroke causes a delay of two to three seconds — which is quite painful.

To solve this, I added a filtering feature that allows users to exclude certain file extensions or directory paths.
Users can configure this in res://addons/script-ide/quickopen/filter_config.tres.
By default, the .import suffix and .godot directory are included as examples for users to follow, even though Godot already filters them out at the engine level.

I also added two switches to enable or disable these filters.

All of the changes take effect immediately — there’s no need to restart the plugin or the engine.

These improvements make a noticeable difference when dealing with tens of thousands of assets files,
though I fully admit that adding so many files to a game project is quite a foolish thing to do.

Here are a few example screenshots:

Default state

Filtered out the “素材 (assets)” path

Filtered out .md extension

Filters kept but switches turned off

[Maran23]

I think we should simplify that further. Just having the exported variable at the quick_open_panel.gd, without another class. And empty be default.

Rationale: I think this is more of advanced feature that is rarely needed and therefore used. So it can be 'more hidden', but still discoverable enough if it is needed. What do you think?

[revaraver]

Thanks for the feedback!
For my own project this implementation already works well, and at the moment I don’t really have the time to refactor it into the export-variables version you suggested.

If you have the time and feel it’s worth adjusting the implementation, please feel free to modify this PR in whatever way fits the project best.
And if you don’t have the time, closing it is totally fine as well — no worries at all.

Maybe at some point, if I have more time available, I might come back and submit a new PR with an export-variables approach.

Thanks again for taking the time to review!