Fixes to support TSMC18 technology port

[ckdur]

List of changes:

hierarchy_layout.py:

• Support for the minimal areas. Only activated to "tsmc18" strings in the tech_name.

pgate.py:

• Whenever a port is created in any gate, it does not put the minimum area requirements. Seems like is assumed to be routed afterward, but if a further via comes, the via-stack violates the minarea. Added only to support tsmc18, but can support any if remove the "if"
• Minimum area for nwell and pwell bulk contacts. Just adds center-vertically additional area with its respective implementations. (Only for tsmc18)
• Avoid the overlap of pimp and nmos when adding a n/pwell bulk connection. New DRC added for this purpose (pimplant_to_nimplant / implant_to_active, works for all techs)
• Fixes for extending implants in gates, taking the implant_enclose_active.

pre-charge.py:

• Same bulk connections fixed also in the pre-charge.py module. This does not work with pgate.py.
• Implant expansion (tsmc18 only)

column-mux.py:

• Same bulk connections fixed also in the column-mux.py module. This does not work with pgate.py.

ptx.py:

• Inclusion of enclose_width and enclose_height, which are different if the "implant_to_channel" is different than "implant_enclose_active".
• Spice LVS detection inside the "lvs_spice" tech variable. Auto-detectable if not defined in the other techs.

pand[2/3/4].py:

• Expansion of the implementation only in tsmc18. There is original no need for the other techs, as the imp can be with the active.

pnand[3/4].py:

• A hackish to displace the ports. Added one m1 pitch only in case of tsmc18.

This source passes the scmos tests using magic + netgen. No tests for freepdk45 were done.

Thank you very much for considering this pull request.

[mguthaus]

I will try to integrate some of these changes later, but right now they are hacks rather than parameterized additions to the tech file. In general, we don't allow technology specific code in the main compiler. I did this temporarily for sky130 but have removed it now, so I don't want to go down that path in the future.

The general procedure for modifying a constant is to make the default value the current value and then add a capability to over-ride it in the tech file. For example, we did this in sky130 for a number of things like custom_layer_properties.