Removing this as a blocker for 2.1.0.

There doesn't appear to be a good answer here for markdown2.
Regardless of which way you configure it, you won't get parity.

I think the way forward here needs three things.

1) Properly set up config for markdown.

This includes a keyword in the [markdown] section (e.g. renderer) to
select the rendering engine: one of markdown, markdown or mistune.
This is similar to how indexing is configured (xapian, woosh,
native).

Per back end config settings. Either:

  markdown2_code_friendly=True/False
  
to enable/disable code friendly mode.

It may be possible to allow multiple settings depending on the
renderer list of strings as options, we can just pass the setting
along:

   markdown2_options = code-friendly, foo_bar_enable ....

If it accepts a dict of strings maybe:

   renderer1_options = key:value, key:value

can be processed as a new options_dict type.

IIRC at least one backend expects it's own objects and not strings for
customizing. Not sure how we handle that. May need specific flags for
each option we chose to support.

2) rewrite the code in cgi/templating.py to use the selection and options
   mechanism.

3) After handling the configuration, create a doc/markdown_use.txt file
to document markdown use and the [markdown] config items. Discuss
current issues with the different backends (search tracker for
markdown). It should discuss how the jinja template integrated
simplemde. It can include my example rest renderer as a
example (see msg6815 and surrounding msgs in issue2550856).