fix: respect map.annotation string

[keithamus]

As per the PostCSS docs on sourcemaps the opts.map.annotation option can be set to a string, to write a manually named sourcemap file:

• annotation boolean or string: indicates that PostCSS should add annotation
  comments to the CSS. By default, PostCSS will always add a comment with a path
  to the source map. PostCSS will not add annotations to CSS files that
  do not contain any comments.

  By default, PostCSS presumes that you want to save the source map as
  opts.to + '.map' and will use this path in the annotation comment.
  A different path can be set by providing a string value for annotation.

  If you have set inline: true, annotation cannot be disabled.

This PR fixes PostCSS-cli to acknowledge this option, and refactors getMapfile to return opts.map.annotation if the option is set to a string.

[RyanZim]

Code looks good to me.

There's a unit test for lib/mapFile.js here that needs fixing since the function signature changed:

postcss-cli/test/map.js

Line 76 in 745ad2c

t.is(getMapfile(p.input), p.want)

Also, an integration test using map.annotation would be great, although not required.

[keithamus]

@RyanZim I've fixed up the unit tests to take the correct objects. I've also added an extra case to show what happens when annotation is provided.

Happy to add extra integration tests if you feel them necessary. Could you please point to where I might add them?

[coveralls]

Coverage increased (+0.5%) to 76.316% when pulling 3b09732 on keithamus:fix-respect-map-annotation-string into 745ad2c on postcss:master.

[coveralls]

Coverage increased (+0.5%) to 76.316% when pulling 9a5e383 on keithamus:fix-respect-map-annotation-string into 745ad2c on postcss:master.

[RyanZim]

LGTM

[RyanZim]

Released in 7.1.0 🎉