fix: account for multi-line comments in tokens, improve comment style

[jorenbroekema]

Issue #, if available:

fixes #952

Description of changes:

• Account for multi-line comments, by splitting them up in the final comment string.
• Put multi-line comments above the token, making it more readable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jorenbroekema]

I added a second commit with a small change that allows formatting prop to be user-passed, even if the format is css/sass/less/stylus, as well as a small change to allow passing commentStyle "short-above" or "long-above" to ensure the comment is put 1 line above the outputted property, rather then inline next to it.

Let me know if those two things are okay or you prefer it some other way or via a separate PR

[dbanksdesign]

Overall looks good, just a few minor things! Thank you!

[chris-dura]

I added a second commit with a small change that allows formatting prop to be user-passed, even if the format is css/sass/less/stylus, as well as a small change to allow passing commentStyle "short-above" or "long-above" to ensure the comment is put 1 line above the outputted property, rather then inline next to it.

Let me know if those two things are okay or you prefer it some other way or via a separate PR

Should this have documentation updated as well around the additional options for commentStyle?

https://amzn.github.io/style-dictionary/#/formats?id=fileheader

---

Related, are these types incorrect? The types listed here say the options for commentStyle are "short" | "long" | "none"...

style-dictionary/types/FormatHelpers.d.ts

Line 21 in 0272b8f

commentStyle?: "short" | "long" | "none";

[jorenbroekema]

I added a second commit with a small change that allows formatting prop to be user-passed, even if the format is css/sass/less/stylus, as well as a small change to allow passing commentStyle "short-above" or "long-above" to ensure the comment is put 1 line above the outputted property, rather then inline next to it.
Let me know if those two things are okay or you prefer it some other way or via a separate PR

Should this have documentation updated as well around the additional options for commentStyle?

https://amzn.github.io/style-dictionary/#/formats?id=fileheader

Related, are these types incorrect? The types listed here say the options for commentStyle are "short" | "long" | "none"...

style-dictionary/types/FormatHelpers.d.ts

Line 21 in 0272b8f

commentStyle?: "short" | "long" | "none";

Good catch, thanks: #1047