Adds targets phing task to allow target definitions in project.yml

[steveworley]

Closes #290.

Adds a new phing task targets that attempts to located defined targets for a particular key for a specified point in the process.

Project.yml can be updated to include target definitions

targets:
  ci:
     validate:
       composer: true
       lint: true
    drupal:
       install: true

The task will take a given key in the targets definition and flatten the yaml into phing targets which can then be called. In the example above validate => composer => true gets translated into validate:composer.

When using the targets task you specify a key to look for in the targets yaml definition like:

<targets
      key="ci"
      property="targets"
      file="${repo.root}/project.yml"
      default="validate:all,ci:setup,tests:all" />

If project.yml doesn't contain the key specified, the targets listed in default will be used instead.

This PR only updates the ci:build:validate:test target.

[grasmash]

Hm.

This approach seems like it would require refactoring every single target.

Is there a way that we could design this to be more 'opt-out' rather than 'opt-in'. E.g., at the beginning of Phing execution we check for all targets that are false and replace them with a "disabled target" that outputs "this target is disabled. skipping."

[grasmash]

Closing this in favor of #458

I've re-used a bit of your code @steveworley, thanks!

[steveworley]

@grasmash I don't think it would require refactoring targets; only the targets that planned on using the <targets> task. It would require that if you were customising the targets to run you would need to know how they're nested.

Eg. When CI is validating the build I want to run PHPCS; your project.yml file would look like.

targets:
   ci:
      validate:
          phpcs: true # validate:phpcs when looking for a target.

If you deviate from the default you would need to be explicit in which targets are run at each point. This approach would allow us to add the <targets> task to other parts of BLT to allow project.yml to control what is being run.

A use case I can see for this is customising what the pre-commit hook runs per project.