Added read events repository

[RichyBaldwin]

• Added read events repository interface and implementation
• Fixed typo

[iblazhko]

LGTM, but this change brings the question about overall library design.

Now that we are exposing interface to read events "as-is", I may also need to run custom appliers on that set, in the same way BullOak does.

Basically, what I am trying to say is that it may make sense to consider different interface for the event store where a user of the library can supply an explicit appliers / projection implementation, to better separate events reading from running appliers.

Here is a snippet for the possible interface definition

type EventStream<'Event> =
    { StreamId : EventStreamId.T
      Version : StreamVersion.T
      Events: 'Event seq }

type EventStreamProjection<'Event, 'State> =
    { New : EventStreamId.T -> 'State
      Apply : 'State -> 'Event -> 'State }

type EventStreamSession<'Event, 'State> =
    { GetStream : unit -> Async<EventStream<'Event>>
      Fold: EventStreamProjection<'Event,'State> -> Async<'State>
      AppendEvents: 'Event seq -> unit
      Save: unit -> Async<unit> }

type EventStore<'Event, 'State> =
    { Get: EventStreamId.T -> Async<EventStreamSession<'Event,'State>>
      Delete: EventStreamId.T -> Async<unit>
      Contains: EventStreamId.T -> Async<bool> }

(note the Fold in EventStreamSession that runs user-supplied function)

Anyway, that's probably for @skleanthous to ponder about, I am not really sure if this change will actually be useful.

This PR LGTM as it is.

[iblazhko]

"the load process should succeed" looks redundant given we are checking for "I should see all the events"

Tests below do not check for "the load process should succeed" and I think this is how it should be.