Remove PSY dependency from parser, and parse to OpenAPI dicts and a database

[hannahchubin]

Summary

• Introduce ParsedOpenAPIObjects, a typed intermediate representation of
  PowerModelsData dicts targeting PowerOpenAPIModels (POM) component types
• Decompose PSS/E transformers into the POM shape: one TransformerCircuit
  per winding, referenced by id from TwoWindingTransformer and
  ThreeWindingTransformer holders. Replaces the older Transformer2W /
  TapTransformer / PhaseShiftingTransformer
• Add make_database: writes the typed collections into a SQLite database
  via a new src/dbinterface/ layer (schema.sql, triggers.sql,
  TABLE_SCHEMAS, OPENAPI_FIELDS_TO_DB, db_write.jl), ordered so
• Subtype-inheritance DB layout: TransformerCircuit,
  TwoWindingTransformer, ThreeWindingTransformer,
  DiscreteControlledACBranch, TwoTerminalLCCLine, TwoTerminalVSCLine,
  FACTSControlDevice, SwitchedAdmittance, and
  InterruptibleStandardLoad share their parent's table, with entity_type
  preserving the concrete class
• Adopt POM.ImpedanceCorrectionData (drops the local shim)
• src/pm_io/psse.jl: emit Dict (not NamedTuple) for the nested MinMax
  limit fields on LCC / VSC / DiscreteControlledACBranch so
  OpenAPI.from_json can construct them
• Consolidate PM/OpenAPI helpers, IDGenerator, and
  _MAKE_DATABASE_TYPE_ORDER into src/definitions.jl

Tests

New coverage for the POM/DB pipeline (previously untested):

• test/test_parse_to_openapi_objects.jl (37 assertions) — typed
  collection counts against case14.raw and case16_all_components.raw,
  transformer decomposition invariants (each 2W → 1 circuit, each 3W → 3
  circuits), holder → circuit id references, cross-component id
  uniqueness.
• test/test_make_database.jl (36 assertions) — DB row counts by
  entity_type match parse_to_openapi_objects output, subtype-inheritance
  coverage for all 7 subtypes on case16_all_components.raw, dedicated
  transformer table counts, arcs and 3W FK integrity, and the on-disk
  path kwarg.

[jd-lara]

I'd remove the DB writter in this PR for now since we need to still make the SiennaGridDB compliant with the new schemas.

[luke-kiernan]

We're using boatloads of strings and symbols here. Those aren't compiler-friendly as a type hierarchy or a Val([scoped enum]).

Now, we don't build systems in hotloops, so we don't need to optimize the heck out of this code. But imo someone should measure how much the type instability and runtime dispatch is costing us. [This could be deferred to post "Sienna 1.0."]

[luke-kiernan]

FK?

[luke-kiernan]

Ick. Not very compiler-friendly. Ideas:

• Symbol and AbstractString instances aren't good for multiple dispatch. I'd consider making table_name and/or col_name Val-types instead.
• Does hasproperty here really need the instance c, or just the type? I suspect the 2nd, in which case we should be using a type parameter: c::T and then write !hasproperty(T, k).
• There's only 2 runtime calls: val = getproperty(c,k) and JSON.json(val). Rest are determined by table_name and col_name. Makes me think about @generated.

Many of these comments apply to the below functions in this same file.

We're encoding "here's a dozen different possibilities" here. When that's the case, imo there's 2 performant options:

1. Create a scoped_enum and pass Val([enum instance]).
2. Create a type hierarchy and pass types.

The downside of (1) is that constructing Val instances at runtime is slow; the downside of (2) is that it scales poorly and puts strain on the compiler's function lookup table.