Improve separation of build targets for specific types of projects

[raamdev]

Forking from discussion in #76 (comment).

We need to think about the intended use for each of the projects where we use Phing and group them according to similarities in the steps necessary to produce a public release. Then we need to design our build targets to apply to those types of projects. Here's a grouping that comes to mind:

• WordPress plugins/themes
• WebSharks libraries

With that in mind, we could have build targets with names like -build-wp, -build-all-wp, -build-lib, -build-all-lib, etc.

We've come a long way with our Phing build system without hitting a divergence point (which came up in #76, but was later resolved by a change in the Comet Cache project).

The "Cleanups" classification @jaswsinc mentioned, referring to the new -js-css target, makes it clear that some projects will need to generate a .~build/ directory, make some changes to its content, and then package that directory for distribution. (Currently packaging happens before .~build/ is populated and the packages are sourced from the repo directory, not the .~build/ directory.)

So we should create -build-wp and -build-lib targets, and let those contain collections of other targets that apply to the appropriate project type.

[jaswrks]

Some (some) progress on this in: #83

[jaswrks]

Some progress on this in https://github.com/websharks/phings/releases/tag/160416