Make kicad-library-utils into one or more packages on PyPI

[Ratfink]

Initially suggested in #68, it would be great if we were to make the kicad-library-utils into one or more Python packages, installable from the Python Package Index. This would be a major undertaking, bringing with it quite a few improvements:

• Stability. Reorganizing the repository as a package could make it easier to write unit tests to verify that the checking scripts work as they're supposed to. This repository could then have its own CI. Making versioned releases would allow library contributors to use a known-good local copy of the checking scripts.
• Documentation. Every public-facing API would have easily readable documentation, allowing third parties to know how to e.g. write new symbol generator scripts easily. This could in turn allow us to move the symbol generators themselves out-of-tree, and they could target whatever library version they need without fear of being broken by changes to the library-utils.
• Efficiency. Installing a single release of the kicad-library-utils with pip instead of cloning a whole git repository could make CI for the kicad-symbols and kicad-footprints repositories run faster.
• Consolidation. Presently there are several Python representations of footprints and symbols used in different parts of the repository. These could be merged into one API for each type of library that would allow us to write both checking scripts and generator scripts.

Of course, there are lingering questions about how this should be done, and even what should be done.

• How should it all be organized?
  • Should the repository become one big package, or should it be split up into several smaller packages kept in separate git repositories?
  • Scripts should be rewritten as executable modules or packages, but where exactly would they live in the new package?
• Should the KiCadSymbolGenerator package be merged with our other symbol library code now, or should we wait until the .sweet format is finalized?

To make sure we don't lose focus, I'd suggest we hold off until the 5.0 release to start working on this. I'd just like to get started on the discussion, as I'm sure that alone will take a while as we work out the details.

[Ratfink]

Starting to work on #231, I see a lot of changes that should be made to the KicadMod class. It would be great to have classes to represent footprint elements, rather than just shoving everything into dictionaries and lists as we do now.

[Ratfink]

Some of the footprint checks are using increasingly complicated geometric calculations. Others aren't correct in some cases because the geometry gets too complicated for us to want to implement it ourselves. As such, I think it would be a good idea to use a third-party library for our geometry calculations. One I found that looks quite powerful is Shapely. I'd of course be happy to hear other suggestions as well; I won't claim to have done an especially thorough survey of Python geometry packages.

[johnthagen]

This would be really great it were on PyPI!

Definitely would make it much easier to integrate into other Python applications.

[johnthagen]

Should the repository become one big package, or should it be split up into several smaller packages kept in separate git repositories?

I'm not a maintainer, but FWIW it seems like it would be simpler to keep it as one big project. Users can just import what they need but I think it will help users to have a single repo to report bugs / submit fixes.

Scripts should be rewritten as executable modules or packages, but where exactly would they live in the new package?

Executable scripts could be exposed through setuptools console entry points.

[poeschlr]

This repo will not be split up! If pip does not support having several packages in one repo then this is a major flaw on their part.

[johnthagen]

If pip does not support having several packages in one repo then this is a major flaw on their part.

pip has no such limitation, so there should be no problems. It's up to users how they want to organize their repo(s).