Features/non generic result

[Artem-Romanenia]

Attempt to address following issues:

• Add Unit Type to Support Void Methods and requests for non-generic Result types #80
• Support non-generic Result #77
• New Feature: Add support for void returns #65
• Add non-generic Result type to support void methods #41

Brief overview:

• Added class Result : Result<Result> (looks a little tricky but this way no Unit class is needed, inspired by FluentResults)
• There are a couple of seemingly questionable details which will make sense later:
• • New Result class has a set of static factory methods for creating Result instances almost equivalent to such in Result<T>.
• • Result also has static generic factory methods for creating Result<T> success-instances
• • Result<T> has an implicit cast from Result
• These quirks allow simplified Result<T> creation in consumer code:
• • Success scenario:

// instead of
return Result<string>.Success("result");
// we can have
return Result.Success("result");
// because Result contains 
public static Result<T> Success<T>(T value)
// that utilizes type inferrence

• • Failure scenarios:

// instead of
return Result<string>.NotFound();
// we can have
return Result.NotFound();
// because Result<T> contains 
public static implicit operator Result<T>(Result result) => new Result<T>(default(T))
{
    Status = result.Status,
    Errors = result.Errors,
    SuccessMessage = result.SuccessMessage,
    ValidationErrors = result.ValidationErrors,
};
// which would be triggered in a typical scenario like
public Result<string> GetStrings(SomeCriteria criteria)
{
    //Do something
    return Result.NotFound(); //This generates Result instance which is casted to Result<string> right away
}

• Last described scenario has a downside of basically creating two result objects instead of one. But I figured it is acceptable since result object is pretty small anyways, plus failure scenarios should occur much less frequently than success scenarios. Plus, there are still factory methods in Request<T> that will not cause any casting.

Also, there seem to be no braking changes, at least I didn't have to change any existing tests.

If this PR has any potential, but you want me to refactor something, please let me know.

[Artem-Romanenia]

@ardalis I'd be happy to hear your feedback on whether any of this makes any sense

[ardalis]

Sorry I've been busy - thanks for pinging me. This looks great based on your comments above.

[ardalis]

...and the build failure is nothing to do with your code...

[ardalis]

Looks great, thanks! Merged!