Revert change on menu_links identifier logic from #2385853

Background

In menu_links_features_export_render(), an identifier is generated for each menu link.
The identifier is generated from data in the menu link itself (menu name, link title, link path).
The database record in the 'menu_links' table is updated, and the identifier is stored in $menu_link['options']['identifier'].
The same identifier is then written to the exported feature, both in the *.info file and in the generated hook.

Before commit 65b07ca, this database record was updated each time the link was exported, based on the newest values (menu name, link title, link path).

Since commit 65b07ca from #2385853-6: menu link shows as overridden: options identifier showing in default, not in overrides, the identifier in the database stays the same once it exists.

However, the identifier written to the feature is still a newly generated one, which may no longer be the same as the one stored in the database for the record.

Problems

Problem: Lack of tests, spec, explanations

One problem is that the commit was not properly explained in the issue.
The desired behavior was not discussed.
The issue summary does not contain steps to reproduce, and it is not clear how the commit relates to the original report.
Possible side effects were not discussed.
No test cases were added.

Regression: Menu link removed from feature on repeated change + export

See #2385853-9: menu link shows as overridden: options identifier showing in default, not in overrides.

Steps:

• Create and export menu link. Commit the feature in git.
• Modify menu link title or path.
• Export again (drush fu -y my_ft_menu). Commit in git.
• (optional) Export again (drush fu -y my_ft_menu). Commit in git.
• Modify the menu link title or path, again. (different value than before)
• Export again (drush fu -y my_ft_menu). Show diff.

Expected:

• (optional) Second export leaves the feature unchanged.
• Third export changes the exported menu link.

Actual:

• (optional) Second export leaves the feature unchanged. (-> good)
• Third export removes the link from the feature.

Why?
The identifier in the exported feature changes, but the identifier in the database remains the same.
On the second export, features can still do a successful lookup based on link path and link title.
On the third export, features no longer finds the menu link in the database.

Solution: Revert

Revert commit 65b07ca.

Known issues

The solution proposed here will fix the problem described, but it will also recreate problems that existed before commit 65b07ca.

Known issue: Duplication of links

The following misbehavior exists in 7.x-2.11, was fixed with 65b07ca, and will come back by reverting 65b07ca:

Steps:

• Create and export menu link. Commit the feature in git.
• Modify menu link title or path.
• Export again (drush fu -y my_ft_menu). Commit in git.
• Revert the last git commit, to restore the previous version of the feature.
• Revert the feature (drush fr -y my_ft_menu).

Expected:

• Link is restored.

Actual:

• A new link is created, in addition to the existing link.
  The reason is that the stored link now has a different identifier than the exported link.

Future

Any new attempt to do this needs to include steps to reproduce, and a big picture analysis.
Ideally it should also contain test cases.

This said, perhaps it is better to leave the 'menu_links' component alone and tell people to use Features Menu UUID instead.