Set makexpi.sh as executable, for convenience of use.
Revert commit 85ca21de42070a0e5f38e5e7d7638609ffa901ad, to allow
findClosestLoadedTab to work again.
Limit the scope of the nearest-loaded-tab search to the current tab group.

When using tab groups, one ordinarily wants to treat each tab group as
its own mostly-separate entity, with no real connection to the other
tab groups in the same window. As such, selecting a tab from a
different group as the "nearest loaded tab" is unexpected, and
generally undesirable.

To avoid that, limit the scope of findClosestLoadedTab() to only the
current tab group, as embodied by the current tabbrowser.visibleTabs
array.

The previous findClosestLoadedTab() searched tabbrowser.mTabs in both
directions from a starting index of the current tab's _tPos variable.
While visibleTabs itself provides a suitable substitute for mTabs,
there is no available equivalent to _tPos - nor can there be, since
the contents of visibleTabs are apparently replaced wholesale every
time the user switches to a different tab group.

To obtain a viable starting index, we therefore scan visibleTabs for
the current tab.

We also check any candidate tab from the "shortcut" or "fallback" code
to make sure it's in visibleTabs. A side effect of this is that we are
no longer guaranteed to be able to find a suitable tab, unless it is
safe to assume that (visibleTabs.length > 1) means that at least one of
the current tab's previousSibling and nextSibling are in visibleTabs.

If we do end up with no suitable tab, we return null, just as if there
had been only one visible tab to begin with. This seems to produce
the intuitively correct behavior in all cases where it actually
happens.
Explicitly use adjacent tabs from visibleTabs in the fallback case,
rather than relying on previousSibling or nextSibling, since there
is apparently not even a likelihood (much less a guarantee) that
either of those will be in the same tab group.
Use aTab.nextSibling rather than aTab as the starting index for
findClosestLoadedTab in the case when the tab was closed rather than
unloaded.

When searching for the closest tab to a tab which is being closed, the
current tab is removed from the visibleTabs list before the BarTab
onTabClose hook ever gets called, so scanning the array never finds it
and we end up with the wrong index. As a result, in such cases we
would always end up selecting the last (or perhaps last loaded) tab in
the array, even when there were suitable ones closer to the current
tab.

To avoid this, do two things. One, use aTab.nextSibling as the tabIndex
if it's found before aTab is, and test appropriately to make sure we
don't accidentally re-select the current tab as a result. Two, make
sure that the tabIndex is always strictly less than the array length,
so that we can fall back properly in the event that no loaded tab is
found. (I believe this latter is actually a bugfix regardless.)
Prefer the first tab to the left over the second tab to the right when
choosing the nearest tab in the case where the current tab was closed.

Since aTab has already been removed from visibleTabs by the time we call
findClosestLoadedTab in the case of onTabClose, and since we therefore
start with an offset of 0 instead of 1, we can end up checking two tabs to
the right before we check one tab to the left. The sequence is:

  scan for tabIndex, and find aTab.nextSibling first (since aTab is not in visibleTabs anymore)
  check tabIndex + 0 (aTab.nextSibling), which is unloaded
  check tabIndex - 0 (aTab.nextSibling), which is unloaded
  check tabIndex + 1 (aTab.nextSibling.nextSibling), which is loaded
  return

And we never checked tabIndex - 1 (aTab.previousSibling), even though it
would be the better choice if it were loaded (since the effective new offset
of the closed aTab is actually tabIndex - 0.5).

To avoid this, in the case of tabIndex+0, we preemptively increment our offset
from 0 to 1, check tabIndex-1, then re-decrement the offset again. I've worked
a number of examples, and they all seem to produce the correct result, both
where the previous code does and where it does not.
Limit the scope of the "unload other tabs" function to the current set of
visible tabs, rather than all tabs in the current window.
Add a pref to let the user choose whether the scope of "unload other tabs"
should be "visible tabs" (i.e. tabs in the currently active tab group) or
"tabs in the current window".
Use a lowercase "U" for the displayed preference-pane text for the
unloadOtherTabs scope pref, for consistency with the other prefs.
When no loaded tabs are available, correctly fall back to only adjacent tabs
even when tabIndex does not point to aTab (such as when aTab has just been
closed).
Avoid code duplication in unloadOtherTabs in handling the
unloadOnlyVisibleTabs pref.
Drop Seamonkey support for now.

Seamonkey doesn't implement Panorama, so the entire visibleTabs approach
won't work. To support both Seamonkey and Firefox, two parallel sets of code
would be necessary, including probably two options dialogs.

While this might be doable (especially if we also make the visibleTabs
approach a configurable option even in Firefox), it might also be better to
simply have Seamonkey support be a separate add-on.