feat: Refactor `IImage` properties to align with DSL

[jacobjmarks]

What does this PR do?

• Modifies IImage properties to align with DSL
  • Adds string Registry
  • Removes string Name
• Modifies DockerImage constructor to align with new properties
• Modifies MatchImage.Match(string) method to appropriately extract new properties
  • I used regex to do so. While the "requirements" shouldn't change, I'm happy to refactor to something a little more maintainable.

Why is it important?

Aligns terminology used with that of the general Docker/container DSL.

Related issues

• Resolves #740

Follow-ups

• Does this new support for registries make the hubImageNamePrefix parameter obsolete?

[netlify[bot]]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	40f14ad3c5ae1ac7339007b641bbc03ead946d76
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-dotnet/deploys/64c4bdd3f380ce00089d256a
😎 Deploy Preview	https://deploy-preview-962--testcontainers-dotnet.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jacobjmarks]

In this case, should the hubImageNamePrefix simply be considered the registry? I assume it will take precedence over any registry defined in the repository argument?

How do you want to handle the DockerImage constructor? I would look to do something like the following however it will clash with existing DockerImage(string, string, string) references.

// current constructor
[Obsolete]
public DockerImage(string repository, string name, string tag, string hubImageNamePrefix = null)
    : this(hubImageNamePrefix, $"{repository}/{name}", tag) { } // <-- forward to new constructor

// new constructor
public DockerImage(string registry, string repository, string tag) { }

[HofmeisterAn]

Sorry for the late response, I was not able to reply earlier.

In this case, should the hubImageNamePrefix simply be considered the registry? I assume it will take precedence over any registry defined in the repository argument? Like we are doing in GetHostname().

Yes, I think that make sense. Do you think we can remove the registry in case the repository argument (obsolete constructor) contains one? This will probably support most backwards compatibility.

How do you want to handle the DockerImage constructor? I would look to do something like the following however it will clash with existing DockerImage(string, string, string) references.

I have thought about that too. I do not think we can avoid a "breaking change", but I think the impact is very small.

• Not many developers will use this constructor.
• Internally, we use only the full name. I do not expect any issues 😬 (besides some existing tests).
• The old properties will still be available and marked as obsolete.