render PlantUML diagrams as (interactive) SVGs

included as
```
<object type="image/svg+xml"
```
to support hyperlinks.

The options for SVG images are documented at https://docs.asciidoctor.org/asciidoc/latest/macros/image-svg/.

Signed-off-by: Manfred Hanke <manfred.hanke@tngtech.com>

docs/userguide/004_What_to_Check.adoc

@@ -4,7 +4,7 @@ The following section illustrates some typical checks you could do with ArchUnit
 
 === Package Dependency Checks
 
-[plantuml, "package-deps-no-access"]
+[plantuml, "package-deps-no-access", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 skinparam component {
@@ -23,7 +23,7 @@ noClasses().that().resideInAPackage("..source..")
     .should().dependOnClassesThat().resideInAPackage("..foo..")
 ----
 
-[plantuml, "package-deps-only-access"]
+[plantuml, "package-deps-only-access", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 skinparam component {
@@ -47,7 +47,7 @@ classes().that().resideInAPackage("..foo..")
 
 === Class Dependency Checks
 
-[plantuml, "class-naming-deps"]
+[plantuml, "class-naming-deps", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -79,7 +79,7 @@ classes().that().haveNameMatching(".*Bar")
 
 === Class and Package Containment Checks
 
-[plantuml, "class-package-contain"]
+[plantuml, "class-package-contain", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -113,7 +113,7 @@ classes().that().haveSimpleNameStartingWith("Foo")
 
 === Inheritance Checks
 
-[plantuml, "inheritance-naming-check"]
+[plantuml, "inheritance-naming-check", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -145,7 +145,7 @@ classes().that().implement(Connection.class)
     .should().haveSimpleNameEndingWith("Connection")
 ----
 
-[plantuml, "inheritance-access-check"]
+[plantuml, "inheritance-access-check", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -183,7 +183,7 @@ classes().that().areAssignableTo(EntityManager.class)
 
 === Annotation Checks
 
-[plantuml, "inheritance-annotation-check"]
+[plantuml, "inheritance-annotation-check", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -216,7 +216,7 @@ classes().that().areAssignableTo(EntityManager.class)
 
 === Layer Checks
 
-[plantuml, "layer-check"]
+[plantuml, "layer-check", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -270,7 +270,7 @@ layeredArchitecture()
 
 === Cycle Checks
 
-[plantuml, "cycle-check"]
+[plantuml, "cycle-check", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 

docs/userguide/006_The_Core_API.adoc

@@ -87,7 +87,7 @@ The domain objects represent Java code, thus the naming should be pretty straigh
 commonly, the `ClassFileImporter` imports instances of type `JavaClass`. A rough overview looks
 like this:
 
-[plantuml, "domain-overview"]
+[plantuml, "domain-overview", svg, opts=interactive]
 ----
 @startuml
 skinparam hyperlinkUnderline false
@@ -207,7 +207,7 @@ For example, every `JavaField` allows to call `JavaField#getAccessesToSelf()` to
 code units within the graph that access this specific field. The resolution process through
 inheritance is not completely straight forward. Consider for example
 
-[plantuml, "resolution-example"]
+[plantuml, "resolution-example", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -244,7 +244,7 @@ member within another class. If a member is queried for `accessesToSelf()` thoug
 will resolve the necessary targets and determine, which member is represented by which target.
 The situation looks roughly like
 
-[plantuml, "resolution-overview"]
+[plantuml, "resolution-overview", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -290,7 +290,7 @@ Second, why can there be more than one resolved methods for method calls?
 The reason for this is that a call target might indeed match several methods in those
 cases, for example:
 
-[plantuml, "diamond-example"]
+[plantuml, "diamond-example", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 

docs/userguide/007_The_Lang_API.adoc

@@ -246,7 +246,7 @@ detailed about fields, methods or constructors. A generic API will never be able
 every imaginable concept out of the box. Thus ArchUnit's rule API has at its foundation
 a more generic API that controls the types of objects that our concept targets.
 
-[plantuml, "import-vs-lang"]
+[plantuml, "import-vs-lang", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 

docs/userguide/008_The_Library_API.adoc

@@ -55,7 +55,7 @@ More precisely, the following holds:
   contain dependencies on any `adapter` package.
 
 
-[plantuml, "onion-architecture-check"]
+[plantuml, "onion-architecture-check", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 
@@ -357,7 +357,7 @@ Diagrams supported have to be component diagrams and associate classes to compon
 The way this works is to use the respective package identifiers (compare
 `ArchConditions.onlyHaveDependenciesInAnyPackage(..)`) as stereotypes:
 
-[plantuml, "simple-plantuml-archrule-example"]
+[plantuml, "simple-plantuml-archrule-example", svg, opts=interactive]
 ----
 [Some Source] <<..some.source..>>
 [Some Target] <<..some.target..>> as target
@@ -600,7 +600,7 @@ The `CCD` of the system divided by the `CCD` of a balanced binary tree with the
 
 ===== Example
 
-[plantuml,"lakos-example"]
+[plantuml, "lakos-example", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 skinparam component {
@@ -690,7 +690,7 @@ so it makes sense to only consider those classes to calculate the *A* value.
 The following provides some example where the `A` values assume some random factor
 of abstract classes within the respective component.
 
-[plantuml,"martin-example"]
+[plantuml, "martin-example", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 skinparam component {
@@ -755,7 +755,7 @@ The metrics are composed from the following definitions:
 
 ===== Example
 
-[plantuml,"dowalil-example"]
+[plantuml, "dowalil-example", svg, opts=interactive]
 ----
 skinparam componentStyle uml2
 skinparam component {