Feat(avd_to_containerlab): Add role to generate containerlab topology

[titom73]

Change Summary

Initial support of containerlab to build l3ls-evpn topology from
EOS-DESIGNS.

Require: avd in version 3.x & PR #1000

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Documentation content changes
• Other (please describe):

Component(s) name

arista.avd.eos_designs_to_containerlab

How to test

---
- name: Build containerlab topology
  hosts: DC1_FABRIC
  connection: local
  gather_facts: false
  tasks:
    - name: 'Build a containerlab topolgy'
      import_role:
        name: arista.avd.eos_designs_to_containerlab
      vars:
        mgmt_network_v4: 10.73.0.0/16
        ceos_version: arista/ceos:4.25.2F

Checklist:

• My code has been rebased from devel before I start
• I have read the CONTRIBUTING document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have updated molecule CI testing accordingly
• All new and existing tests passed (pre-commit, make linting and make sanity-lint).

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[ClausHolbechArista]

This approach will only work if the target for the play knows about all nodes. Since this role should run after
eos_designs, I would prefer if we could read some of the generated data, instead of having to maintain the datamodel here as well.
I believe most of it should be in the structured_config including peer-switch information.

[titom73]

Considering this role will be only for CI, local testing, it would be part of a specific playbook meaning the previous playbook will have to save debug files to make facts available in another play or playbook.

So user experience would be more complex than reading eos_designs inputs.

[ClausHolbechArista]

I meant reading structured_configuration instead. So we can change eos_designs freely without affecting this one.

[titom73]

Using structured_config files will create constraint when eos_cli_config_gen is similar to the current relationship with eos_designs and will also make rendering more complex:

• Run task for one host.
• Load structured_config for all hosts with a per-host approach to saving data.
• Read structured_config to generate file.

Where the current implementation just reads existing inventory variables.

Note: this PR is only for the eos_designs approach