Serve (at least) documentation embedded in extension jar

[mdutoo]

For now, the Studio has documentation features, but its output can't be easily viewed at runtime, and is not really interesting (quite empty) for now.

An easy improvement would be to serve documentation files embedded in extension jar through HTTP, so that it can be displayed by a web browser or the OCCInterface functional playground (which allows more interesting features such as executable JSON REST samples, even better if embedded see #49 ).

Doing this will open up more possible features:

• also serving generated textile doc. Ex. ad a javascript textile engine in OCCInterface.
• but also models (extensions, configurations, in OCCI or EMF format), "erocci" XML, alloy. For instance, they could then be linked from the generated doc for easy download.

=> TODO cgourdin API that allows to reference and download files within the extension maven jar, TODO cdorothe use it to display below the JSON a div that lists all those files to download AND an HTML display of textile doc thanks to a javascript textile engine.

And further (don't do it but only study it) :

• unifying OCCInterface sample semantics with Eclipse-generated doc: either add OCCInterface JSON sample semantics to textile doc, or define in EMF generic (XML / JSON / text) sample semantics and let OCCInterface support it, possibly helped by additional MART REST services

How to do it:

• define what's doc by file extension (.md, .textile ; and possible .xml, .occie, .occic, .als). Also specifying directory within jar (erocci/*.xml...) can help prevent leaking out passwords within OCCI configurations, but will never be enough though.
• build a JSON (or / and HTML, but JSON is more versatile) index of all doc. Either generate it for each jar along with the doc in Eclipse, or introspect all jars at MART startup, or some of both.
• serve the index from ex. /doc or /content (or from / BUT WITH some mimetype ex. doc+json) and doc files from /doc/jarOrExtension/pathInJar (or from / but with some mimetype(s) ex. text/plain ??)

NB. https://github.com/occiware/org.occi.catalog could be used instead as index format (with JSON as one of its representations by virtue of being defined in OCCI). It could also be used instead as a developer-defined index (but an introspected or generated index will stay more up to date), or as a REST catalog server's model (but MART is the best OCCI REST server we have right now, so the OCCI catalog should rather be developed on top of MART).