Add static has build optimization

[kitsonk]

Type: feature

The following has been addressed in the PR:

• [X] There is a related issue
• [X] All code matches the style guide
• [x] Unit or Functional tests are included in the PR

Description:

This PR allows build optimization using the has feature detection library. During the build process, any static features that have been asserted are used to replace call expressions that look something like has('feature'). For example, if feature foo was set to true as a static flag, this code:

import has from `@dojo/has/has`;

if (has('foo')) {
  console.log('has foo');
}
else {
  console.log('does not have foo');
}

Would be transformed to this:

import has from `@dojo/has/has`;

if (true) {
  console.log('has foo');
}
else {
  console.log('does not have foo');
}

Then further during the build process, if the build is being minified, uglify will detect the dead code and rewrite it further to something like:

console.log('has foo');

At the command line, users are abstracted from individual flags, and instead supply a set of feature flags they wish to use. The supported sets are located in src/features/*.json. These are specified by the user by setting the -f or --feature flag on the CLI. Multiple feature sets are combined to produce the largest set where the values do not conflict. For example es6-promise is true on chrome but false on ie11. If chrome and ie11 were specified, the values would conflict and this feature would not be statically bound.

A user supplying multiple platforms would look something like this:

$ dojo build -f chrome safari firefox

Which would produce a build that is statically built with features that are common between Chrome, Safari, Firefox.

At the moment, most of the shim library isn't written to have polyfill code within has() guard blocks, therefore it doesn't get removed from the build when the native feature is statically expressed. We will need to revisit those modules in order to create something that builds optimally.

Todo:

• [x] - test cases
• [x] - readme/documentation

Resolves #142

[kitsonk]

Two thoughts on this...

• In the original issue, I suggested -t and --target. I am not sure which makes overall better sense. Or even something else?
• There is no support for user defined flags. I think that is fairly critical, but I suggest we tackle that as a separate issue/PR after we land this one. I think using .dojorc to specify custom features which will be mixed in to any other targets makes the most sense.

[kitsonk]

This now requires dojo/shim#101 for the sets of features to actually be effective.