Maintain back-compat for admin bar 'appearance'

[nacin]

We removed the 'appearance' menu in 3.3. It's fair to say that other plugins may have added nodes there.

What I think we should do is not only offer a parent translation, but to also keep the existing items under appearance. It feels cleaner overall, and reduces the risk of clashing with plugin modifications. Thoughts?

[ryan]

On the other hand, plugins can continue adding to the old id for < 3.3 compat and use the new one for 3.3+ compat and everything will be nicely targeted. I think admin bar menu back compat can be much more relaxed than we are with the admin menus.

[jane]

I'll side with Ryan.

[nacin]

Agreed.

[nacin]

In [19365]:

Handle 'appearance' as a admin bar menu parent in a backwards compatible way. fixes #19245.

[nacin]

Now I remember why I considered making 'appearance' canonical. If we ever want to incorporate the entire admin menu, we can simply scrap the appearance items all together and render it automatically. Now, we may have additional submenu items added by plugins floating next to the top-level items.

[nacin]

Now that we have groups, we can have an 'appearance' group.

[nacin]

In [19434]:

Use an 'appearance' group in the admin bar. fixes #19245.

[nacin]

The mapping code was revived in #19426.