Data type of global exclude list

[ACTCD]

The current global exclude list takes the same data format as @match metadata in the settings, it uses the match patterns defined in the browser extension API, not sure if this is the best data format for the end user, it might cause some difficulties.

Although we added a error indicator for it in #341 #339, we still can't be sure users know how to fix it.

It now uses the same function in the swift layer as script injection to check this list, which is fine, but in the future we may migrate it to the javascript layer, maybe in background or content scripts, so that we can do it earlier handle it and save some unnecessary message requests and processing.

Considering the possible implementation of #334 in the future, we may eventually need to implement the same @match metadata parsing function in the javascript layer, which is not too much of a problem. But the global exclude list can also be decoupled from the script injection process and checked before it, so we can choose to use other formats as well.

Once the #331 work is complete, we will have the ability to make changes to it. So bringing this discussion up here, as well as documenting some of my current thoughts, let's think about what data format would be more appropriate.

Considering that to the end user, the global exclude list might be more specific to some site i.e. host domian, rather than a path, maybe a syntax like @include metadata is easier for the end user, it's also easier in javascript easy to accomplish. If necessary, we may be able to provide both ways for users to choose in the future.

[quoid]

Giving users more options for the exclude list would be a good thing. We should ensure we don't negate any potential performance benefits we get from moving the exclude list check from the swift to the javascript layer as well with the introduction of additonal data types. We should think about the data structure for the exclude list when migrating to the javascript side - do the type check and validation at save time rather than at injection time.

Additionally it wouldn't be a bad idea to add some help text to the exclude list in the settings modal. The placeholder text really doesn't direct the user enough and within the help text we could include links to the README.md.

parsing function in the javascript layer, which is not too much of a problem

Also, the javascript equivalent userscript parser.

[ACTCD]

Due to the proposal of #650, implementing global exclusion based on @include is no longer considered.

Additionally we've nicely improved the error prompt about match patterns in #613.