Add browser.profile setting and fix Firefox addArguments bug

[aomarks]

This PR adds a new browser.profile JSON config setting which can be used like this:

{
  "benchmarks": [
    {
      "url": "mybench.html",
      "browser": {
        "name": "firefox",
        "profile": "/Users/<username>/Library/Application Support/Firefox/Profiles/<profile-name>"
      }
    }
  ]
}

It also fixes a bug where addArguments was not being applied to Firefox, even though it was documented that it was supported.

For Chrome, it was previously supported and documented to use "addArguments": ["user-data-dir=<path>"] to achieve this same effect, but I found that the equivalent for Firefox ("-profile=<path>") caused Selenium to timeout trying to connect to the process. I wasn't able to figure out exactly why this was happening, but I did notice a dedicated setProfile method just for Firefox, which does work. So by adding the browser.profile setting, we now have a way to call this special API, plus the user doesn't need to remember the user-data-dir flag in Chrome.

Fixes #222

cc @guybedford

[AndrewJakubowicz]

LGTM.

A couple non blocking questions:

• How was this tested?
• Does this need any additional test coverage?
• Not totally clear what the parsed.profile change in the SafariConfig interface is for. Is it compatibility with the Chrome/Firefox interfaces?

Thank you!

[AndrewJakubowicz]

Nit: sable?

[aomarks]

Oops, should be "disable". Fixed, thanks!

[AndrewJakubowicz]

For me it was under Profile Folder. Maybe different versions of Firefox? I tested on Firefox 92.0

[aomarks]

Huh, interesting. On Linux it's "Directory" and on macOS it's "Folder" for the same version. That seems like some pretty unnecessary localization! Added both.

[guybedford]

I just tested this out here and it works perfectly for me. Thanks so much for filling in the gaps on this workflow @aomarks it's a huge help!

[aomarks]

• How was this tested?
  I tested it manually in Firefox/Chrome on Linux and macOS.

• Does this need any additional test coverage?

It would be nice to have an automated test here, but I think it's pretty tricky. I think we'd need to serialize a profile for each browser somehow, and then have a way to figure out from the results if we actually launched with that profile or not. Maybe the profiles would have an extension installed that inject a value or something? I think I must punt for now 😬

• Not totally clear what the parsed.profile change in the SafariConfig interface is for. Is it compatibility with the Chrome/Firefox interfaces?

I don't think this change is actually affecting SafariConfig, it's just an illusion because of the way GitHub automatically folds part a file when showing a diff. It's the configfile.ts file, but the parseBrowserObject function.

• Not totally clear what the parsed.profile change in the SafariConfig interface is for. Is it compatibility with the Chrome/Firefox interfaces?

[aomarks]

Oops, should be "disable". Fixed, thanks!

[aomarks]

Huh, interesting. On Linux it's "Directory" and on macOS it's "Folder" for the same version. That seems like some pretty unnecessary localization! Added both.

[AndrewJakubowicz]

Oops! I was completely fooled by that code folding. Thanks for answering my questions.

[aomarks]

Also threw in a fix to tests relating to chromedriver having updated to Chrome 94 while GitHub Actions is still on Chrome 93.