Provide distributed (per-module), current, and stylistically coherent diagrams

I'll try to centralize the various threads between myself, @DenisCarriere, @rowanwins, @stebogit and anyone else who has been talking about images for the documentation.

• #1152 @denis sets up so that every module can have its own ./images directory. This moves us toward solving the first half of this goal, having distributed (per-module) images/diagrams. They are, of course, optional for any given module.

• #1140 @rowanwins brings up the issues of generalization, which suggests their being handled in the same way but also,

• #1128 as @stebogit notes, they should (but not must) use a consistent visual language.

Proposal:

1. Require all diagrams to be .svg format, following the naming convention of turf-${decamelizeName}.svg, say, or turf-center.svg. This sets up a problem when an image is duplicated, but svg is light enough that maybe that's not an issue and can be handled programmatically on build?

2. Have Travis/etc. build a .png of the .svg on build, if modified. I'm not an expert on this, but I can't imagine it'd be difficult to implement.

3. Build a .css style-sheet for the svg graphics, where we can use class names to provide visual consistency (stroke width, fill opacity). Looking at Esri's docs, it seems that there are a small number of primitives that have to be defined: a handful of polygon styles, points, and that's about it. These could either be enforced at the css level or

4. Bundle the .svgs together in an editable .pdf. Inkscape can pull pages from this pdf and work on them one at a time (though I'm not sure how rebundling it would work), while keeping them together in a single pdf allows for "master" changes in Illustrator. Now that the idea of using css has hit me, I'm a little less driven by the promise of visual consistency provided by having n artboards in AI. This pdf would be broken up into svgs, of course, and each svg would end up where it belongs on build.

Start by reviewing the related discussions in #1152, #1140, and #1128, then inspect the documentation image layout and existing Travis configuration. The issue proposes several alternatives but names no files or tests; done would require settling the SVG, PNG, styling, and editable-PDF workflow before implementation.