parameterized hierarchical symbols

hierarchical symbols currently only support a single static implementation, when the implementation itself could be more dynamic.

my prime example will be a voltage regulator symbol, implemented by a buck regulator. in a static setup, its .sym would be a box labelled "3.3V regulator", with appropriate inputs and outputs. its implementation in the .sch would contain the workhorse chip, inductor, diode, and some resistors, all with fixed values. i'll call this component a "break-out symbol", for it does in schematics what a breakout-boards typically provide: a chip with its core supporter components.

in my use case, i want to have two instances of that on my top-level schematic, once for 5V output, and once for 3.3V output.

ideally, i would insert the break-out symbol into my schematic, open its attributes, and change the output voltage from the default 3.3V to 5V. the symbol's appearance would change (in this case trivially, as the 3.3V label could just be the visible attribute), and some of the components' values would change. a similar, simpler version of the break-out symbol might instead offer direct access to the resistor values. a more complex and abstract break-out symbol might even choose to use a different topology in background when a certain voltage threshold is exceeded. (thus, there would be symbols whose parameters only influence the bill of materials by changing `values` or `nobom`, and others that change what ends up on the pcb, eg by changing the `graphical` or a `source` attribute)

implementing this can be divided into sub-tasks:

* variable access: the symbol implementation (the .sch file) needs to have access to its outer symbol's attributes. bug 911440 seems to address this, but seems to be dormant, and packs parameters into extra attributes (parameter=RFB:12k instead of RFB=12k -- unless for good reasons, i'd rather take the direct approach). this would need to work both in the nested .sch file and in the displayed .sym file.

* expression evaluation: this starts with numerical expansion (think value=r_total * 1.25 / v_out) and boolean algebra (think nobom=not extended_version) and ends in language wars and code execution hell. as local attributes should be accessible as well (usable eg. for constants like v_ref=1.25), cycles could appear. definitely needs some thought.

* configurable promotion: currently, attributes are promoted if visible or in a (per-project?) configured list are promoted. to ease accessibility of parameters a symbol exposes, it might be practical to have a way to say per-symbol which parameters should be promoted.

* flexible symbol choice: while a symbol's source can be overridden by setting a source= attribute, there is no way of changing which symbol is used at a position on the fly (currently, the way to go is to detach the attributes, delete and replace the symbol, and re-attach the attributes). in connection with variable access / expression evaluation, this would be useful both in changing the visual appearance of a symbol and in switching out implementations. care must be taken by the user to only switch around schematic-compatible versions.

* net / line nobom or hide attributes: while all changes in appearance and net connectivity could be done by stacking appropriate symbols (at least after flexible symbol choice is implemented), designing flexible symbols might be easier if a net could be made `graphical=v_out < 4.8` to indicate that it should be only considered real at higher voltages. (the term `hidden` might be more appropriate here, but graphical is already established for components). same goes for graphical components like lines and arcs (but might be harder there since they don't have attributes at all)

* visual representation: both the gui and the printouts could use an option to print formulas instead of actual values. possibly, this could be per-attribute setting (like now is showing name and value).

* interactive symbol and schematic design: unless only the formula is shown, for editing a .sym or .sch file it suddenly does make a difference in which context the file is viewed. when opened as part of a hierarchy, the upper levels' variables could be used for display. there could be an option in the gui to ignore the context (only the variables or default values indicated locally would be used), or to explicitly set a context. as things can be nested, the complete context is a sequence of 2-tuples of .sch files and the refdes used in there.

other uses:

* jumper symbols that can be switched between default-open and default-closed by setting an attribute, and change their symbol and nobom (in case of solder jumpers) or device (in case of pin jumpers) accordingly

* chips with different pin numbering in different packages (pinno=footprint=="QFP32" ? 99 : footprint=="DIP28" ? 11 : "")