[SIM] Rework emulator

I think the idea makes sense. Being able to quickly spin up something like 100 virtual EtherCAT slaves is genuinely useful for testing and scaling scenarios.

That said, I’d push for a single, consistent way of defining the network rather than supporting multiple input modes. Right now we have:

"-n <number_of_slaves>" (implicit generation)
multiple JSON configs (explicit definition)

Maintaining both introduces ambiguity and increases the surface for bugs and inconsistencies over time.

A cleaner approach would be to move everything into the JSON config and make it the single source of truth. For example, the slave count (or generation rules) could live inside the JSON itself. That way:

the configuration is self-contained
the interface stays simple (one input method)

Also, I think we’re currently mixing concepts a bit between ESI and ENI:

ESI (EtherCAT SubDevice Information): describes what a slave can do (capabilities, PDOs, objects, etc.), typically provided by the vendor.
ENI (EtherCAT Network Information): describes how slaves are actually instantiated and connected in a specific network (topology, mappings, runtime configuration).

Right now, the simulator interface seems to blur those two responsibilities. Ideally:

the JSON should act more like an ENI (network definition)
reusable slave descriptions should stay closer to ESI-like definitions

Not blocking for this PR, but I’d see your change as a good stepping stone toward a more standard, EtherCAT-aligned configuration model.

What do you guys thing?

No files, tests, or entry points are named. Start by locating the simulator interface that handles -n and JSON configs, then inspect how slave descriptions and network definitions are represented. Done should mean a single JSON-driven network definition with a clear separation between reusable slave capabilities and network instantiation.