Added option to preserve list numbering from input

[prust]

@chjj: I'm not sure if you're interested in merging this feature, but I figured I would issue a pull request just in case.

Our use-case: Our app has large blocks of technical content in the form of ordered lists and there is occasionally block-level content in the list items (tables, multiple paragraphs, etc). The block-level content breaks up the list, so when a list is resumed, the actual numbering from the input should be used instead of starting over at "1".

I realize that the more semantically correct thing in this case would be to output a single list with the block-level content nested in it -- and this is possible with some markdown implementations (RedCarpet) but it places additional burden on the user to indent the block-level content beyond the indent of the list item it belongs in. Instead of going that route, this simple workaround gives the user more control and meets the user's expectations (I'm sure the end-users of our app would be surprised by markdown's default behavior -- as I was -- of ignoring the numbering from the input).

I added tests for the option, which pass when it the option is enabled (but a couple of pre-existing OL tests fail when the option is enabled because they aren't expecting the value attribute in the output <li>s). When the option is disabled (the default), the only pre-existing tests that fail are the 4 that normally fail (10-14). I added a preserveNumbering condition to tests\index.js so the new tests are skipped if the option is disabled. When disabled, the new option has a negligible effect on benchmark performance. When enabled, it adds, on average, about 50-70 milliseconds to the test time on my machine (~2%).

[lepture]

@prust have a look at my pull request #129

The renderer feature will make it easy to do any customisation.

[gkoberger]

Thanks, this is perfect. This should be in marked.

@lepture I love the renderer, but couldn't figure out how to make this work without forking. Any thoughts?

[VioletPixel]

This would be a very welcome addition.

There is currently no viable way to use a custom renderer for this, as the renderer functions don't provide any arguments containing the number of the list item, just the content of said list item. If the listitem function were passed a second value argument containing the list item's number, or a prefix argument with whatever comes before the content of the list item that would make the renderer approach viable.

[joshbruce]

Closing due to staleness and merge conflicts. Still an interesting feature - added to #956 as a note.