feat: open importing to anything in lib

[KTibow]

should make building custom plugins easier

motivation: #2165 (comment)

[KTibow]

At some point I want to execute this sprint (although not at a sprint's pace):

• Support external lib imports (this PR)
• Write a plugin with the sole purpose of doing what convertColors's currentColor currently does and document it widely (code, docs, release changelog)
• Deprecate currentColor (reasoning I've heard: it's not an optimization so it doesn't belong in core, and it lacks many community requested features)
• Release a new version
• Close issues and PRs regarding currentColor

[SethFalco]

I'm not going to block this PR, but I will weigh in with an opinion!

I don't think it's a great idea to expose the lib/ directory directly, as this adds too much cruft to our supported interface. I especially do not want us to expose our directory structure in the API.

Would you mind creating an lib/index.js file and just exporting all the functions that make sense to you in it? (Even if that's all of them.)

Then people can do this for example:

import { stringifyPathData, computeStyle } from 'svgo/lib';
// stringifyPathData from lib/path.js
// computeStyle from lib/style.js

This way you can achieve what you want, which I appreciate—perhaps I was a bit overzealous when sealing up our supported interface.

If we do this, perhaps consider deprecating anything I had exported at svgo that will now overlap with the exports to svgo/lib. For example, we export some helpers like querySelectorAll already, but if we'll officially export helpers for plugins, then they can all just reside in the svgo/lib export.