All .gliffy files replaced by .svg (#199)

All .gliffy and .png files depicting event graphs replaced by .svg. Relevant .md files updated accordingly.

The test-execution-sequence diagram is preserved: this should eventually be replaced with a reference to Eiffel Sepia, but that requires rephrasing the example documentation and will have to wait.

Also fixed a number of typos and mistakes in the graphs.

eiffel-syntax-and-usage/compositions-and-validity-checking.md

@@ -24,7 +24,7 @@ Using the __data.dependsOn__, __data.implements__ and __data.requiresImplementat
 ### Checking Dependencies
 In this straight forward example, the integration of a system requires the presence of an interface and a third party library. Consider the following composition:
 
-![alt text](./composition-dependency-check-example.png "Dependency Checking Example")
+![alt text](./composition-dependency-check-example.svg "Dependency Checking Example")
 
 Here composition C2 is legal, but C1 is not. The reason is that B1 requires version "[1.1.0,)" of com.example:a (that is, version 1.1.0 or later). In composition C1 there is no such artifact, but in composition C2 there is.
 
@@ -33,7 +33,7 @@ Note that the [Maven version range syntax](http://maven.apache.org/enforcer/enfo
 ### Checking Backend Implementation Validity
 In this example we imagine a microservice setup. The service interface I has no implementation itself - instead it requires one or more implementations to which it can forward requests. There are multiple versions of the interface included, affording clients backwards compatibility.
 
-![alt text](./composition-backend-implementation-example.png "Backend Implementation Validity Example")
+![alt text](./composition-backend-implementation-example.svg "Backend Implementation Validity Example")
 
 Composition C1 is not valid: it contains two instances of A, one of I1 and one of I2. A implements I from version 1.0.0 up to, but not including, 2.0.0. Hence, I2 is lacking implementation is this composition.
 
@@ -52,5 +52,3 @@ _Isn't this a reinvention of the wheel?_ you may ask. After all, there are plent
 It should also be noted that Eiffel's dependency syntax is opinionated. An interface requiring supporting implementation does not dictate that it requires any particular implementation (actually it can - simply use __data.dependsOn__). Rather, it is up to that implementation to declare that it supports the interface. This is in order to encourage separation of concerns and decoupling.
 
 Furthermore, Eiffel's dependency syntax makes no distinction between e.g. build time and runtime dependencies. This is for two reasons. First, it is not intended for low level dependency management: most programming languages have dedicated and specialized tools that will handle this type of dependency management. Instead, where Eiffel's comes into play is in tracking and validating large, sprawling systems of heterogeneous artifacts. Second, even if one attempts to develop specific syntax each type of dependency there will always be corner use cases which are not covered: better then to err on the side of abstraction, rather than implicitly ruling out use cases by being overly specific. That being said, it is also generally the case that an artifact has a fair idea of its intended use - it is rare that one and the same artifact is both a deployable service and a source code library, with the need to declare a unique set of dependencies for each case. Hence, the EiffelArtifactCreatedEvent dependency declarations shall be read in context.
-
-

usage-examples/build-avoidance.md

@@ -23,16 +23,16 @@ A common use case in continuous integration and delivery systems is avoidance of
 
 In a centralized scenario where everything is handled in a single orchestrating job, this is relatively straight forward: analyze the change, trigger the needed builds, wait for them to finish and package the result. In a decentralized continuous integration and delivery system based on descriptive (rather than prescriptive) principles a different approach is needed.
 
-Compared to many other examples, only a very small number of link types is included: __ELEMENT__, __PREVIOUS_VERSION__, __REUSED_ARTIFACT__ and __COMPOSITION__. These four are the types relevant to the example; other link types are of course legal and feasible, but not included here. 
+Compared to many other examples, only a very small number of link types is included: __ELEMENT__, __PREVIOUS_VERSION__, __REUSED_ARTIFACT__ and __COMPOSITION__. These four are the types relevant to the example; other link types are of course legal and feasible, but not included here.
 
 A JSON array of all events used in this example can be found [here](../examples/flows/build-avoidance/events.json).
 
 ## Event Graph
-![alt text](./build-avoidance.png "Event Graph of Build Avoidance Example")
+![alt text](./build-avoidance.svg "Event Graph of Build Avoidance Example")
 
 ## Event-by-Event Explanation
 ### SCS1, SCS2
-The [EiffelSourceChangeSubmittedEvents](../eiffel-vocabulary/EiffelSourceChangeSubmittedEvent.md) signal that source changes have been submitted to a branch of interest (typically a shared development branch or "mainline"). They would normally point to [EiffelSourceChangeCreatedEvents](../eiffel-vocabulary/EiffelSourceChangeCreatedEvent.md) documenting the change in greater detail; for the sake of brevity this has been left out of the example. 
+The [EiffelSourceChangeSubmittedEvents](../eiffel-vocabulary/EiffelSourceChangeSubmittedEvent.md) signal that source changes have been submitted to a branch of interest (typically a shared development branch or "mainline"). They would normally point to [EiffelSourceChangeCreatedEvents](../eiffel-vocabulary/EiffelSourceChangeCreatedEvent.md) documenting the change in greater detail; for the sake of brevity this has been left out of the example.
 
 ### CDefC1, CDefC2
 For each source change, a new [EiffelCompositionDefinedEvent](../eiffel-vocabulary/EiffelCompositionDefinedEvent.md) is emitted, including it in __ELEMENT__ links. Note that each composition references its predecessor via a __PREVIOUS_VERSION__ link.