Introduce service container

[Kittyfisto]

Current behaviour

Currently, plugin interfaces such as IFileFormatPlugin.Open(string fileName, ITaskScheduler taskScheduler) are very rigid, yet are expected to call constructors of objects from Tailviewer.Core, such asTextLogFile(ITaskScheduler scheduler, string fileName, ITimestampParser timestampParser = null, ILogLineTranslator translator = null, Encoding encoding = null). This is all fine and dandy, however what happens if TextLogFile requires another dependency (for example a custom list of log levels, see #184)? Do we break plugin compatibility for every new dependency?

Expected behaviour

Plugins should not break because tailviewer needs to forward more dependencies through a plugin to one its own classes. In other words, if a plugin wants to modify the log line translation aspect of a file, then it should not be expected to care about any other aspect of log files.

Concrete implementation

Introduce a service container interface such as:

public interface IServiceContainer
{
    T Resolve<T>() where T : class;
}

and break plugin compability only once by changing the following method signatures:

• IFileFormatPlugin.Open(string fileName, ITaskScheduler taskScheduler) => IFileFormatPlugin.Open(string fileName, IServiceContainer services)
• ILogAnalyserPlugin.Create(ITaskScheduler scheduler, ILogFile source, ILogAnalyserConfiguration configuration) => ILogAnalyserPlugin.Create(ILogFile source, ILogAnalyserConfiguration configuration, IServiceContainer services)
• IDataSourceAnalyserPlugin.Create(AnalyserId id, ITaskScheduler scheduler, ILogFile logFile, ILogAnalyserConfiguration configuration) => IDataSourceAnalyserPlugin.Create(AnalyserId id, ILogFile logFile, ILogAnalyserConfiguration configuration, IServiceContainer services)
• IWidgetPlugin.CreateViewModel(IWidgetTemplate template, IDataSourceAnalyser dataSourceAnalyser) ==> IWidgetPlugin.CreateViewModel(IWidgetTemplate template, IDataSourceAnalyser dataSourceAnalyser, IServiceContainer services)

This change will allow tailviewer to inject any future dependency into plugins without breaking backwards compatibility on plugins: Plugins will not need to be re-compiled in case tailviewer needs to pass yet another dependency to one of its classes (such as TextLogFile). The downside to this is obviously that if a plugin author requires a given dependency, then it will be harder to find out how to obtain it (since it's no longer part of the static singature).
Therefore this change requires better documentation on tailviewer's part.

Constraints

• Do NOT introduce additional dependencies in TV's nuget package (i.e. neither Tailviewer.Api nor Tailviewer.Core may contain references to unity or other DI frameworks)
• Tailviewer.Core should maintain a simple IServiceContainer implementation where singletons are registered with the container (this is to not require every plugin author to implement this interface in case he/she wants to write a test for their plugin):

class ServiceContainer
{
    public void RegisterInstance<TService, TImplementation>(TImplementation service) where TImplementation : TService where TService : class
    {
         _services.Add(....);
    }

    public T Resolve<T>()
    {
        return _services.Get<T>(...);
    }

• Tailviewer (the main project) may implement IServiceContainer by re-using existing DI frameworks, but it doesn't have to - mabye the ServiceContainer as part of Tailviewer.Core is enough at first

[Kittyfisto]

TODO:

• Add IServiceContainer interface to Tailviewer.Api
• Add ServiceContainer implementation to Tailviewer.Core
• Modify the following classes' constructors to accept an IServiceContainer instead of ITaskScheduler (they should obviously resolve() the task scheduler):
• EventLogFile
• FilteredLogFile
• LogFileProxy
• MergedLogFile
• MultiLineLogFile
• NoThrowLogFile
• TextLogFile
• AbstractWidgetViewModel
• LogAnalyser
• Increase the PluginInterfaceVersion of any plugin who's signature changes as part of this issue:
• IFileFormatPlugin
• IDataSourceAnalyserPlugin
• ILogAnalyserPlugin
• IWidgetPlugin
• Use this chance to finally implement refactoring of IDataSourceAnalyser (since that would break compatibility as well)
• Tag all interfaces which are now served through the IServiceContainer (maybe a remark in its documentation, maybe an attribute)
• Write new plugin compatability tests
• Update plugin documentation now that method signatures have changed

[Kittyfisto]

Fixed with Tailviewer v1.0.0-RC1.