Update docs regarding IDisposable and IAsyncDisposable support.

Author: Code-Grump

docs/automation/context-injection.md

@@ -11,7 +11,7 @@ To use context injection:
 Rules:
 
 * The life-time of these objects is limited to a scenario's execution. 
-* If the injected objects implement `IDisposable`, they will be disposed after the scenario is executed.
+* If the injected objects implement `IDisposable` or `IAsyncDisposable`, they will be disposed after the scenario is executed. If they implement both, only `DisposeAsync` will be called.
 * The injection is resolved recursively, i.e. the injected class can also have dependencies. 
 * Resolution is done using public constructors only. 
 * If there are multiple public constructors, Reqnroll takes the first one.

docs/execution/parallel-execution.md

@@ -48,7 +48,7 @@ When using Reqnroll we can consider the parallel scheduling on the level of scen
     * However, if you still want to use method-level parallelism and a `FeatureContext` in your test suite, then **the following things will be true**:
         * The `FeatureContext` and feature-level DI container will remain consistent **per feature, per test thread**. This means that anything you register in the feature container will be resolvable in the `[AfterFeature]` **per test thread**.
         * A given `[BeforeFeature]` or `[AfterFeature]` will only be executed once **per test thread** that runs a scenario of a feature.
-        * Types you register in the feature-level DI container that implement `IDisposable` will still be disposed **per feature, per test thread**. (Keep this in mind if you try to work around this parallelism behavior to regain singleton-like behavior. E.g. by using static instances, `Lazy<>`, thread-safe collections, etc.) 
+        * Types you register in the feature-level DI container that implement `IDisposable` or `IAsyncDisposable` will still be disposed **per feature, per test thread**. (Keep this in mind if you try to work around this parallelism behavior to regain singleton-like behavior. E.g. by using static instances, `Lazy<>`, thread-safe collections, etc.) 
 * Scenarios and their related hooks (Before/After scenario, scenario block, step) are isolated in the different threads during execution and do not block each other. Each thread has a separate (and isolated) `ScenarioContext`.
 * The test trace listener (that outputs the scenario execution trace to the console by default) is invoked asynchronously from the multiple threads and the trace messages are queued and passed to the listener in serialized form. If the test trace listener implements `Reqnroll.Tracing.IThreadSafeTraceListener`, the messages are sent directly from the threads.