buildpacks - by name + git url fallback

What's the user value of this feature request?

manifest.yml can list a set of buildpacks; but each buildpack can only be listed by either its git url, or its zip URL, or a name if its installed by a platform operator.

This makes it very hard for sample or shared applications, such as https://github.com/starkandwayne/wordpress-for-cloudfoundry, that must provide multiple manifests because they don't know if a target CF will have pre-installed buildpacks or not.

• https://github.com/starkandwayne/wordpress-for-cloudfoundry/blob/master/manifest.yml - manifest with git urls for new buildpack; but these are slow buildpacks since they build libbuildpack bits from source
• https://github.com/starkandwayne/wordpress-for-cloudfoundry/blob/master/manifest.buildpacks.yml - manifest with named buildpacks; but this requires that the user has convinced the platform operator to install the new buildpacks
• another example could be a manifest.yml that has explicit urls to .zip files

Instead, I propose that we change the schema of buildpacks to something like routes - where each item is an object, rather than a simple string; and to allow use to provide all the information about a buildpack:

applications:
- name: wp
  buildpacks:
  - name: pancake_buildpack
    source: https://github.com/starkandwayne/pancake-buildpack
  - name: wpcli_buildpack
    source: https://github.com/starkandwayne/wpcli-buildpack
  - name: php_buildpack  

Who is the functionality for?

Users of Cloud Foundry

How often will this functionality be used by the user?

Whenever deploying shared applications written by authors who do not know the status of your cf buildpacks list.

Who else is affected by the change?

An implementation could continue to support the existing buildpacks: [pancake_buildpack, php_buildpack] schema.

Is your feature request related to a problem? Please describe.

I don't like that I have to curate multiple manifests and document it in projects like https://github.com/starkandwayne/wordpress-for-cloudfoundry/

I'd prefer that users can get a pre-installed buildpack if it exists; or fallback to a git url if its missing.

Describe the solution you'd like

Support both the existing buildpacks: [name1, name2] and new buildpacks: [{name: name1, source: uri1}, {name: name2}].

Also continue to support name or git url in cf push -b name1 -b url2.

Describe alternatives you've considered

See https://github.com/starkandwayne/wordpress-for-cloudfoundry/ - I must curate multiple manifest.yml for end users and hope they understand the reason for each and when to switch.

Start with the manifest.yml and manifest.buildpacks.yml examples, then trace manifest buildpack handling and the cf push -b path. Done means supporting both existing string entries and objects with name and source, including fallback to the source when a named buildpack is unavailable, while preserving name and URL support.