When opening a new tab with `t`, don't set the `openerTabId` to the current tab

[Tijs-B]

Describe the bug

I'm using Vimium in combination with Sidebery. When opening a new tab by pressing t, I don't expect the new tab to be a Sidebery "child" from the current opened tab. This behaviour is caused by setting openerTabId in the tabOptions passed to chrome.tabs.create here to the current opened tab.

I'd expect that opening a new tab (which doesn't originate from a URL on the page) to be opened without setting a openerTabId in the chrome tab options.

To Reproduce

Steps to reproduce the behavior:

1. Install Vimium
2. Install Sidebery
3. Open a webpage such as https://example.org
4. Open a new tab by using Vimium's shortcut t.

Expected behaviour: the new tab is opened as a new "root tab"

Actual behaviour: the new tab is opened as a child from the current tab.

Browser and Vimium version

Firefox version 126.0.1 Vimium version 2.1.2 (Sidebery version 5.2.0, although this doesn't matter)

[UncleSnail]

I can see this as being the correct expectation, and I would recommend a maintainer to look at this and see if it is something that should be changed. However, I can also see a case for the default behavior since using "t" opens the tab directly after the selected one. I personally use "t" when I want a new tab "in context", and ctrl+t when I want a new tab in a "new context," which is the current behavior, so for me it makes sense for tabs created with "t" to be grouped in an extension like Sidebery.

[Tijs-B]

I can indeed see the reasoning behind the current behaviour, so I'm definitely ok with not changing this.