Revise the custom label keys

Background

Core is pretty limited in the way it does entity type labels. You get one label (Node, Commerce Product, OG membership) and that's it.
If you want to refer to the entity type generically through the UI (permissions, forms, buttons), you need more than that.

So, in parallel Commerce and Entity API tried to address this.

Commerce did this:

function commerce_product_entity_info() {
  $return = array(
    'commerce_product' => array(
      'label' => t('Commerce Product'),
      'permission labels' => array(
        'singular' => t('product'),
        'plural' => t('products'),
      ),

Entity API did this:

function entity_test_entity_info() {
  $return = array(
    'entity_test' => array(
      'label' => t('Test Entity'),
      'plural label' => t('Test Entities'),

The Commerce approach to labels is good, the only problem is that "permission labels" is too narrow, since the labels can have much wider use.
The Entity API approach is not good:
1) The plural label is capitalized by default, which means that for many UI contexts it needs to be lowercased. However, this means it can be semantically incorrect in languages such as German (where nouns need to be capitalized) because the case of the translation is not respected.
A better option is to have it lowercase by default, and uppercased in the few cases where that is needed.
2) It only gives us a plural label, instead of having both singular and plural.
This is important because many contrib entity types have the project name in the label (Commerce Product, OG membership), and the actual UI labels need to be without that prefix (product / products, membership / memberships).

Proposal

Let's standardize both Commerce and Entity API on:

function entity_test_entity_info() {
  $return = array(
    'entity_test' => array(
      'label' => t('Test Entity'),
      'ui labels' => array(
        'singular' => t('entity'),
        'plural' => t('entities'),
      ),

I'd also be fine with "ui strings". And the original plural label key could be kept if it would still have a use somewhere, but I doubt it.

Source: #1658458: Support Entity API-provided labels.