Add test-code-coverage command

[mydea]

This PR adds a command ember test-code-coverage. This can be used e.g. in CI environments.

The command can also be used to simply print out the total coverage percentages, e.g. so you don't need to go looking into HTML files for them.

It takes the following parameters:

• target-lines: The target percentage for lines covered
• target-functions: The target percentage for functions covered
• target-statements: The target percentage for statements covered
• target-branches: The target percentage for branches covered

For example: ember test-code-coverage -target-lines=80 -target-branches=85

You can also configure those in the config/coverage.js file, in their camel cased form, like this:

 module.exports = {
    targetLines: 80,
    targetFunctions: 85.5,
  
    // Other configuration
    coverageEnvVar: 'COV'
  }

These values will then be the defaults when running ember test-code-coverage.

Running the command will output something like this to your console:

+ Lines covered:       60.00%   69.17%
+ Functions covered:   --.--%   72.18%
+ Statements covered:  --.--%   68.93%
- Branches covered:    70.00%   60.16%
- Test coverage check failed

For any type of check where no target is specified, it will simply output the actual value without doing any comparison.

[lstrzebinczyk]

Something like this would be very nice, gitlab can parse tests output and make a good use of coverage data out of the box, but it must be provided by the tests command.

[RobbieTheWagner]

@kategengler @adamjmcgrath what do you guys think about this feature?

[RobbieTheWagner]

@kategengler aside from the need for a rebase, are you in favor of this feature in general?

[kategengler]

I am uncertain whether this is something we should be doing ourselves, or deferring to nyc

[mydea]

If you decide to go forward with this, I'll gladly make the changes as requested. :)

[RobbieTheWagner]

@kategengler I also think we may want to defer this to nyc. @adamjmcgrath what do you think?

[adamjmcgrath]

My preference would be nyc support and improving that tool, but I can't offer any help with that at the moment, so don't mind if you want to proceed with this solution.

[RobbieTheWagner]

I agree. I think we should perhaps close, in favor of nyc.