Refactor to support .make files natively; deprecate the manifest format and Apps servers

Problem/Motivation

The current model for App data provision - the use of app servers providing data in a custom format - presents numerous issues.

• Apps don't function offline; see #1621474: Allow Apps to function when offline .
• Data duplication and busy work. Currently distro developers using Apps have to repeat the same information in multiple places and different formats. For the distro, they need to use .make files. In some cases, e.g., Panopoly, each app has its own .make file. But for Apps support, they need to maintain the manifest format required by Apps. Depending on requirements, this second format may be needed in two distinct places, each with its own variant format: in an app server (typically handled by editing a node body) and, if #1621474: Allow Apps to function when offline is applied, in the app's .info file. This duplication leads to significant extra work for apps developers without clear payoffs.
• Available apps lack effective versioning. An app server typically provides the latest app versions, even if these may be incompatible with a given (past) distro release.
• Apps require external infrastructure, arguably detracting from drupal.org based visibility and interoperability; see #1733748: [meta] Enable drupal.org based apps.

Proposed resolution

Allow apps to read the information they need directly from install profiles or apps connector modules in a lightly enhanced version of the existing standard format, the .make file.

In a new Apps branch, refactor to remove use of the manifest format. Instead:

• Apps reads available apps from the a make-format file that ships with either a distro or an apps connector module to determine available apps. In the case of the apps connector module, the make file would have a standard name e.g. apps.make to avoid being handled by drush (since we don't actually want the files downloaded).
• Rename hook_apps_servers_info() to hook_apps_sets_info() and replace the 'manifest' key with 'makefile'. Example for an apps connector module:
  

  function hook_apps_sets_info() {
    return array(
      'example' => array(
        'title' => t('Apps set title'),
        'description' => t('A description of the apps set.'),
        'makefile' => drupal_get_path('module', 'example_apps') . '/apps.make',
      ),
    );
  }

  Example for an install profile. The makefile can be one actually used in building a distribution, as in this example, or one that contains relevant information but is not actually used (in the case that the distro doesn't actually package the app):

  function hook_apps_servers_info() {
    return array(
      'example' => array(
        'title' => t('Apps set title'),
        'description' => t('A description of the apps set.'),
        'makefile' => drupal_get_path('profile', 'my_profile') . '/drupal-org.make',
      ),
    );
  }

• Define apps-specific keys to enhance the .make format, e.g.:
  

  projects[my_app][apps][screenshot] = "http://drupalcode.org/project/my_app.git/blob_plain/refs/heads/7.x-1.x:/screenshot.png"
  projects[my_app][apps][name] = "My app"
  projects[my_app][apps][description] = "My app does stuff."
  // Optional; can be used to override what's defined in the make file e.g.
  // to provide an apps-compatible library download or when the make
  // format uses git or another method that isn't supported by the upload
  // module's limited install functionality.
  projects[my_app][apps][downloadable] = "http://example.com/my_file.tar.gz"

• When an app is downloaded, any .make file in the app's directory is parsed and then the relevant download files determined through querying the drupal.org update server; this code can be adapted from what's in drush make. All files are downloaded before the app is enabled, ensuring that dependencies are met. (One issue to be addressed here is that the update install functionality assumes a particular directory structure, and so won't work with all whitelisted library downloads. See #1571428-4: Cannot use archives that do not extract to folder named after downloadable.)

Implementing this approach could render #1621474: Allow Apps to function when offline unnecessary, as all App data would be available through the .make file. It could also significantly simplify the Apps module code.

Remaining tasks

User interface changes

The user experience for browsing and installing apps would be practically unchanged. The app ranking/voting functionality could be hived off into a separate module.

API changes

Developers would define available apps directly in the code of make files shipping with a distro or an apps connector module.