Refactoring the TestCaseParseResult

[arksap2002]

Description of changes made

Replace OperationResult to TestCaseParseResult to improve error mangment.

Other notes

Closes #293

• I have checked that I am merging into correct branch

[stephanlukasczyk]

Risky, because there is nothing that prevents content from being null, which would lead to an NPE.

[Vladislav0Art]

As a rule, no !! in any code that goes in development. Otherwise, one of the strongest aspects of Kotlin, null-safety, just vanishes.

[stephanlukasczyk]

I am not particularly happy with this API, because it implies IMHO an implicit contract that cannot easily be stated explicitly or enforced:
In my understanding the assumption is that either content or error are set. There is, however, nothing that enforces me to do this—both could be null or set. I am now thinking about how such an API could/should actually look like. Personally, I am in favour of something that does not require such an implicit contract:

data class OperationResult(val result: ElementType)

interface ElementType {}

data class Result(val result: Payload) : ElementType

data class Error(val message: String) : ElementType

Please do not take this API for granted, it's just a proposal of my idea for discussion. Additionally, one would probably want to have this OperationResult type then available in some more global package of TestSpark.

[Vladislav0Art]

Here is a possible implementation:

sealed interface Result<out ValueType, out ErrorType> {
  data class Ok<ValueType>(val value: ValueType): Result<ValueType, Nothing>
  
  data class Error<ErrorType>(val error: ErrorType): Result<Nothing, ErrorType>
}

and then you write extension methods for result checking & retrieval.