Support generating two-terminal footprints with IPC density argument

[evanshultz]

Fixes https://github.com/pointhi/kicad-footprint-generator/issues/421.

Branched from #438. Merge that PR first!

This adds a parameter to support IPC density settings. If the user does not enter a value for the density, nominal density is assumed and footprints are generated exactly as they are now (or, rather, would be if the aforementioned PR is merged). Giving an argument to this parameter generates footprints with correspondingly bigger or smaller pads and a suffix on the footprint name which indicates the density.

It appears the density is used during pad calculation for the handsolder footprints and I've left that alone since it gives further options for handsoldering pads. Or, those footprints can be discarded if the density argument is given and only the non-handsolder footprints added to the library. That would be my expectation.

I feel like there might be a better way to sort out the density during argument parsing than what I added at the end of SMD_package_rlc-etc.py, but my brain feels empty now so I may need to come back to this later. Or get suggestions.

I also renamed the function TwoTerminalSMDchip() to TwoTerminalSMD() because the script can generate non-chip footprints.

[codeclimate[bot]]

Code Climate has analyzed commit 3189413b and detected 4 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Duplication	4

View more on Code Climate.

[poeschlr]

You might have done something wrong with git here. The list of changed files looks strange.

---

Edit: this might be the result of merging combined with the original branch being different to master. Will simply mean that we need to check this locally with better difftools than github. Plus it will need to be squash merged as it will otherwise make the git history horrible.

[poeschlr]

Also a general thing: The size definitions used for this script are massive compromises as these sort of devices are not really standardized. I am therefore not really sure the official lib will benefit from having other densities of these footprints in it. I am however not opposed to adding this feature to the script to allow users to generate their own set of footprints with differing density levels (really only makes sense if the user then also adds their own size definition fitting their device)

[cpresser]

@evanshultz while looking at #438 I also found this PR. The history of this one looks broken. I think its best to fix this branch after #438 is merged.

[evanshultz]

@cpresser Yes, that was my intent. Maybe that wasn't clear above. Sorry.