move markdown parsing to exporter

[neonstalwart]

in addition to moving the markdown parsing to the exporter, this has the following consequences:

• more properties are being picked up on constructors eg dojo/Color now has blendColors, fromRgb, fromHex, etc
• the return-description content is now being consistently parsed as markdown
• parseMarkdown is probably being called more often than what would be ideal because the result is no longer being stored back on the metadata

what do you think? i found (and fixed) a few inconsistencies while doing this.

[wkeese]

I'm glad you fixed those bugs although I'm not sure why you would move markdown parsing to the exporter. It might be a bad idea since theoretical future exporters (i.e. exporting to JSON) would have to repeat the work?

I've got a bunch of changes to the exporter in #60; I hope your changes don't conflict. Maybe we should be developing with my branch as the base, since it's the branch we are using to actually generate dojo's doc.

[neonstalwart]

my goal in moving markdown to the exporter is to actually support more formats - eg for a markdown exporter, i want the raw markdown from the processor and a JSON exporter might export markdown too (markdown vs HTML is a choice that is independent of using JSON as the export format). i think that assuming HTML as being the lowest common denominator might be too restrictive - why not allow each exporter to have the raw markdown?

what might make sense is to eventually have a utility function that an exporter can use to crawl a module (i guess crawling modules would be the right approach?) and convert all the markdown to HTML so that the code for that could be reused across exporters. if/when it's needed, that's something that could be done later though.

[neonstalwart]

80 implements an approach that makes the unparsed metadata available to exporters so now the exporter can choose between parsed or unparsed metadata.