Add partial config file functionality to cEOS

[CapnCheapo]

Added partial config support for cEOS modeled after how it's implemented in vIOS and other node types.

[hellt]

/cc @ankudinov

[ankudinov]

@CapnCheapo Thank you for submitting the PR.
Could you please add following to this PR:

1. Documentation explaining how partial config works. Similar to how it's done for other node types where partial config is supported.
2. Provide steps to test this PR before merging to reduce time required for reviewers to build the lab. @hellt I'd suggest to that as a requirement to Containerlab PR templates.

I'd appreciate if you provide a few use cases where this feature is critical. The motivation is clear in general, but I have a very strong opinion that Containerlab users should always provide a full startup config for every node instead of relying on defaults. This helps to avoid confusion in case of changes on EOS or Containerlab side and guarantees clean start of the lab. However I have a very specific workflow in mind where the full state of the lab is dictated by the Git repo. I imagine that for an average user that can be a useful feature. But would be great to see a few specific use cases where it's a must in the docs. With possible risks highlighted.

[CapnCheapo]

@ankudinov I have attached documentation updates and test cases. Let me know if anything should be updated.

As for critical use cases, I don't think any of this counts as "critical", more of "nice to have" functionality. I have been designing learning labs for users of all levels. It is very convenient to be able to add additional configuration onto a device baseline. I don't want my users to be focused on the management underlay of a lab, but rather the topic being presented. Using partial config, the user can quickly and easily see what has been configured on a device without worrying about how the lab itself is setup. From a maintainer standpoint, this requires much less config to be managed, as well. For more experienced users, this allows for them to cut the amount of time needed messing around with a default config and allows them to get straight to the topic at hand.

It is true that if EOS changes there might be some incompatibilities introduced, but this is not going to be the fault of a partial configuration feature. If something changes, both the standard template as well as any user-defined full configuration files will have to change. If anything, partial config support reduces the amount of config files that need to be changed. Plus, the user is free to override any erroneous config in the partial config as necessary.

Please let me know if you need more information or anything reworked. I am primarily an "old school" network engineer, not a developer, and this is my first major attempt at contributing to a software project, so i have much to learn.