Reimplement tabs

This is step one. There are more steps to be taken but this will reestablish first level tabs to HEAD. The new tab rule is

For a non-tab item, the immediate children of the current path are considered as tabs.
For an item that is tab, the immediate siblings of the current path are considered as tabs. Ie. the immediate children of the parent are considered as tabs.

These rules will be adjusted when the N-level of tabs will be introduced. Stay tuned.

Drupal 5 makes very bold assumptions. Imagine this scenario: someone creates a module which adds a sub-menu item under admin/content/taxonomy named after the vocabulary and makes the path the name of the vocabulary, pathauto like. Now, someone adds a vocabulary for Attention-deficit hyperactivity disorder, thus the path admin/content/taxonomy/add is created. Now, the default path for adding a vocabulary is admin/content/taxonomy/add/vocabulary... and that will nicely disappear from admin/content/taxonomy and will try to appear under admin/content/taxonomy/add but being a single tab it won't appear.

The new rules does not allow such anomalies. So, I needed to adjust some admin paths to match the new rules (note: there were hardly any set-out rules for the old system).

So, N-th level of tabs are the next easy step. n previous Drupal versions we had only two, but that's artificial and I had a contract once to develop a third level. Now, if you look at the second rule above you will quickly realise that this one iterates upwards.

A very tough case is tracker. Here, you have a tab that points to tracker/%. Howevever, that % means 'the uid of the current user, unlike from node/% or user/% type paths where % in the tab paths are simply arg(1). This will be solved by Eaton's token system which is also needed for better breadcrumb solutions in core. It's lightweight and all, but that's a separate issue.