[JS] Enable installAddon() to install unpacked extensions

[snoack]

Description

This pull request extends the installAddon() method of the Driver implementation for Firefox, so that a path to an unpacked extension can be specified alternatively to a packaged XPI or ZIP file.

Motivation and Context

The Driver implementation for Firefox has an installAddon() method in order to install web extensions for the current session. The underlying install addon command can install packaged extensions using the addon parameter, as well as unpacked extensions using the path parameter. Support for the latter is missing in Selenium's installAddon() API.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[CLAassistant]

All committers have signed the CLA.

[snoack]

I'm sorry but I couldn't make the new test pass on the CI (and didn't get the test suite to run locally either). So I'm skipping it with xit for now.

installAddon() completes successfully but then it fails to find the element that the test extension were supposed to inject. I tried adding additional timeouts and retries but it didn't help.

However, when I'm testing these changes in our project, and pass the path to an unpacked extension to installAddon() everything works fine.

At the current point, the only idea left I have is that it might be the version of geckodriver but I didn't figure out yet where the CI is getting its version of geckodriver from, and frankly I spent already more time than I planned on this PR. But if I can get some pointers, I'm happy to finish up the test.

[titusfortner]

This goes along with #8357 & #9494,

The problem with this implementation is that you can't use the directory in a remote server.
As I mentioned in 8357, it might make sense for Selenium to zip/base64 the directory and use addon, but the user can just as easily zip it and provide it themselves right now.

[titusfortner]

Thanks for this contribution, but I'm closing this in favor of the solution in #10216 since that one will support both local and remote driver instances.