Enable use of subsystems in get_components

[jd-lara]

I am opening this issue for discussion to incorporate the notion of subsystems in PSY.

The issue arrises from the fact that for large systems it is strategic to split the system in sub-systems to solve for effectively. Although we have areas and load zones, those definitions conflict with administrative definitions critical for reporting and can be different than the desired split of a system for modeling purposes as is the case in NTP.

Further, it could strategic to split a system in ways that aren't relevant to those administrative definitions for example in Balancing Areas according to their slack bus. These in almost every real data set do not correspond to the same area as defined in the PSSe files.

For the reasons above I am proposing not to use the name Area or Region but subsystem.

The proposed approach is to enable an internal map to System such that we can reference the UUID of a component to a "sub system" in a dict. E.g., Dict{String, Vector{UUID}} and enable an interface as follows `get_components(ThermalStandard, sys, "SubSystemID").

The proposed interface through get_components() would be the minimally invasive approach to incorporate this feature in PowerSimulations.jl

cc. @claytonpbarrows

[GabrielKS]

The current interface to get components in an Area or LoadZone is PSY.get_components_in_aggregation_topology(subtype, system, aggregator) where aggregator is an AggregationTopology instance. Maybe we can refactor this to be just another method of get_components too? And then for consistency we should either refer to subsystems by instances of a subsystem struct or refer to these existing aggregators by string (or both).

[jd-lara]

The challenge here as mentioned above is the fact that even aggregation topologies can be part of subsystems too.