Add support for vr-vsrx (Juniper vSRX)

[Exhar]

Hi,

This PR adds support for the vr-vsrx kind, now that Juniper vSRX is supported by the hellt/vrnetlab fork.

I have (to the best of my ability) copy&pasted everything from the vr-vmx and vr-vqfx kinds into the 'vr-vsrx' and tested the new kind (it works...). Maybe even too much (I am unsure about mkdocs.yml and schemas/clab.schema.json which feels both are generated somehow...)

Hopefully I've updated all docs as well, but if something is missing, I am more than happy to add/update docs.

[hellt]

This is cool stuff @Exhar !
Likely the first PR that was didn't require any changes from the first submit, kudos!

I wonder, as a newcomer, what would you like to be explained better about the onboarding process of a new platform to containerlab? Did you stuck at some point longer than you wanted?
Maybe some docs need to be added?

[codecov]

Codecov Report

Merging #1352 (afdd6a1) into main (8c9b54f) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1352      +/-   ##
==========================================
+ Coverage   20.84%   20.86%   +0.01%     
==========================================
  Files          57       57              
  Lines        6274     6275       +1     
==========================================
+ Hits         1308     1309       +1     
  Misses       4845     4845              
  Partials      121      121              

Impacted Files	Coverage Δ
cmd/generate.go	31.92% <ø> (ø)
clab/register.go	100.00% <100.00%> (ø)

[steiler]

@hellt what I started last week independently, which I think would also ease the impolementation of new kinds is #1347.
Where all the information required for the topology generation is sourced from the .go itself.

[Exhar]

@hellt Thank you for merging! :)

I wonder, as a newcomer, what would you like to be explained better about the onboarding process of a new platform to containerlab? Did you stuck at some point longer than you wanted?

To be honest, its a fairly straight forward process. Most time goes into getting the container-setup working (but that is out of the scope of this project)

Maybe some docs need to be added?
I think it would be beneficial to have a clear list of what is expected when creating a pull request. For example, I didn't bump mkdocs. Is this something you'd like to have done by the person creating the PR or are you more than happy to do this yourself?