Statistics+Tracker menu collision breaks Profile

This is a really weird behavior, observed by me on real site's test-upgrade. A collision between Statistics and Tracker modules disrupts menu system so badly, that User-editing page doesn't show Profile-defined secondary tabs. (Took me whole day to track this down, surely menu system needs some sanity-check to avoid this re-appearing in contrib every other day - but that's for another issue.)

As for this bug here, I tracked the origin to Statistics module, which adds a sub-tab with path user/%/track/navigation, without ensuring that the parent and default-task neighbor entries are there. These are originally provided by Tracker module, which doesn't need to be enabled!

Filling this as critical might be debated, but certainly (in some configs) it completely kills access to user profile edits other than basic account info, making the Profile module useless.

Background: On my site, there's Statistics module enabled, because it's really useful - provides all sorts of admin logs like referrers / top pages / top users and the like. Tracker is NOT enabled, because it's pretty useless if using Views - all Tracker's functionality is replaced by customized views anyway, so no need to load extra code for nothing. So it's a pretty sensible config IMO, nothing extreme.

How to reproduce:
- Fresh 6.x-dev install
- Enable modules Profile and Statistics (but NOT Tracker!)
- Go to Profiles and add a new field
- Go to 'My account' and click 'Edit'.
Expected behavior:
Secondary tabs 'Account' and 'your_fields_category'.
What happens instead:
No secondary tabs. (If you guess the exact URL of the other tab, it works, but still no tabs rendered.)

How the bug happens, for your information:
- Statistics define a tab 'user/%/track/navigation'.
- Tracker is disabled, so the parent 'user/%/track' doesn't exist.
- _menu_router_build() notice the missing parent, and "helpfully" reparent the tab to 'user/%'.
- On page request for 'user/xx/edit/category', the menu_local_tasks() function iterates through all tabs, presuming that tabs of the same level have equally-long paths:
* First secondary tabs on 'user/%/edit/***' are rendered and stored into array, with the key = number of path elements being 4.
* Then it go to parent-level and render primary tabs for 'user/%/***', whose number of path elements is generally 3, excepting the re-parented entry 'user/%/track/navigation' having 4 elements. Unluckily, that entry goes last, so the number 4 remains in variables, and is later used as array key for storing primary tabs. Thus, previously rendered secondary tabs are OVERWRITTEN by primary tabs.
* The resulting array (only one element in this case) is re-sorted to gain zero-starting keys, so primary tabs appear correctly as element #0. Secondary tabs are gone.

The fix: The question of menu system being disrupted so easily and difficult-to-track goes into another issue. But in the first place, defining a tab with non-existing parent is wrong. So I'm attaching a patch for statistics.module, which checks for the Tracker module existence, and moves the offending tab from (wrong) 'user/%/track/navigation' to (correct) 'user/%/track' if Tracker is not enabled. So, the tab is simply elevated to primary-tab position, if there's no lower structure to integrate into. The resulting UI is exactly the same as before, only the tab is now re-parented correctly and so doesn't cause problems.

Patch attached.