Export manifest logic

[rxaviers]

Manifest files are currently created by running grunt manifest task.

In order to give 3rd party applications (eg. download builder) custom control over manifests, eg. ability to merge special _ field (we need a name for this special feature), this PR exports manifest API.

[rxaviers]

This work is in progress. It's pulled now, so we can discuss some things, see below.

[rxaviers]

I placed the manifest code in build/manifest.js. Any other better place?

[scottgonzalez]

That's fine.

[rxaviers]

@scottgonzalez @jzaefferer thoughts? ^

[scottgonzalez]

These are all wrong. None of these pages are categories.

[rxaviers]

If we accept the proposal below, we don't need this PR anymore.
jquery/api.jqueryui.com#152
jquery/download.jqueryui.com#153

[rxaviers]

@scottgonzalez, @jzaefferer we've talked in Portland about adding extra data in UI manifests via the _ extra field, and this PR is such implementation. But, thinking more about it, I'd like to propose the following (addressed by the two PRs commented above).

Right now, we're adding extra data into the manifests to address one issue: let DownloadBuilder know how to expand a documentation category into its corresponding pages and posts. Documentation is the scope of api.jqueryui.com. So, instead of augmenting the manifests here, we could delegate that "responsibility" to api.jqueryui.com.

This new proposal workflow works the following way:

1. jQueryUI manifests keep referencing the category page (when appropriate, eg. ui-core, effects-core);
2. DownloadBuilder figures out how to expand a category into its pages and posts by reading api.jqueryui.com's new categories-manifests;
3. api.jqueryui.com generates such manifest info via a new grunt manifest task.

[scottgonzalez]

I like the api.jqueryui.com approach.