Add a JS API for using the icons on pins & such!

[dschep]

This PR adds a CLI and JavaScript API for pinhead.

features

The API can:

• Return the original icon
• Recolor the icon
• Place it on background shapes with customizable colors: square, circle, map_pin, and marker
• Add a colored stroke (applies to background shape if there is one,, otherwise applies to the icon)

The API also has a function for migrating names from previous versions of pinhead as well as seed sources.

The CLI can(with all the variation options provided by the API):

• Print out a single SVG
• Build a collection of SVGs from a definition in a json file

See the readme for more information

implementation notes

• Only works within the constraints of pinhead icons(15x15. Unstyled paths only)
• Extracts path d values with a regex
• Assembles new SVG with simple string concatenation
• Internally, there are only really 2 / 2.5 shapes. Circles are just squares with an automatic corner radius and markers are just a map_pin with 1px more padding, an automatic stroke (fancier color selection, default width of 1), and an added shadow (this results in something nearly identical to maplibre/mapbox/makiwich markers). The map_pin/marker path is derived from the map preview SVG.
• The CLI uses Node's built in arg parsing bc I don't want to add a dep since an API user woudn't need the CLI deps
• stroke is created by just putting it under the icon (and doubling requested width since half is hidden)
  • does not work with translucent icon color.. could be fixed add clipping to remove the part of the stroke behind the icon (I think this is what you did in themap.is)?

To-do:

• tests. Will probably generate pngs in tests to ensure outputs stay the same visually but can change in svg implementation
• an easy way to migrate a name to a new name using the changelog, including from maki/temaki/etc

future additions

• Custom backgrounds, including PNGs

[quincylvania]

This is so cool! It'll probably take me a bit to review but I'm excited for it.

[dschep]

Open question.. should getIcon implicitly do migrateName(name)? IE: make it mostly future-proof. Or do users need to explicitly choose to future-proof, IE: getIcon(migrateName(name))? The latter feels like too much for what is probably the desired default behavior so i'm leaning to the former. If folks want to be more explicit with their name they can do getIcon(migrateName(name, "pinhead@VERSION")) to explicitly use names from a particular version.