Newlines are not kept in longDescription

[alranel]

As of now, the >- syntax is used for multiline fields. However this will not preserve newlines correctly. For instance:

    longDescription: |
      Agave è composto dai seguenti blocchi logici:

      * Un'**area amministrativa** (CMS)
      * Un **sito web statico** (Jekyll) contenente un **template** Jekyll

will be parsed as:

    longDescription: |-
      Agave è composto dai seguenti blocchi logici:
      * Un'**area amministrativa** (CMS) * Un **sito web statico** (Jekyll) contenente un **template** Jekyll

We need to use |- instead of >-, as explained here: https://yaml-multiline.info

I think this change should only apply to longDescription, where we might expect text with newlines.

[sebbalex]

as for now the editor produce the longDescription field using > operator

[sebbalex]

Library used for yaml conversion manages long string field in a proper logic way. Since this PR#181 related to issue #66 adds this behaviour.
Actually there is no parameter to set folded/literal scalar block.

To achieve our goal we have two ways in front of us:

• go back to html format and use <br /> tag to manage newlines and translate back to markdown in parser.
• set the lineWidth parameter (doc) to force the | operator but we will have very long line in yaml, so bad for readability.

[alranel]

Further testing shows that publiccode-editor generates valid YAML. It tries to be smart to sometimes it uses > and other times it uses |. When > is used, additional newlines are inserted in the document, for example:

foo: >
  * foo
  
  * bar

This seems to be correctly parsed as * foo\n*bar because > collapses multiple newlines, so the round-trip is correct. However, the YAML file becomes not user-friendly and easy to edit because a human would never understand why double newlines should be inserted in a Markdown list.
We probably need a way for forcing | so that the YAML file contains literal strings and stays human-editable.

[bfabio]

This depends on nodeca/js-yaml#515 being merged, unless we want to workaround it.

[bfabio]

@sebbalex @libremente Do we want to vendor js-yaml? An option would be to use patch-package until that PR is merged upstream.