Implement concept of editor modes

[gchp]

This introduces the concept of modes.

A mode is an interface through which the user can use Iota. The goal here is to eventually implement vi-like modes, but also support non-vi-like editing. This non-vi-like editing is the default behaviour in editors like emacs or sublime and many others. I have implement this non-vi-like editing as a mode of its own, called StandardMode. The next step will be to add the vi modes NormalMode, InsertMode and VisualMode.

This first step is really just to see how it will work, and it seems decent to me.

[gchp]

@Crespyl mentioned in Gitter that having the mode as a generic type parameter on the editor would prevent changing modes at run-time. Need to change this to be a boxed trait instead.

[pythonesque]

I think an enum would be a better option than a boxed trait. In general, boxed traits only make sense if you need an open set of possible modes. Enums are much easier to handle in Rust than trait objects (trust me, I've been wrangling with them recently).

[gchp]

You mean have the whole mode implemented as an enum?

enum Mode {
    Normal,
    Insert
}

impl Mode {
    fn handle_key_event(&self) { ... }
}

[pythonesque]

Yeah. You can easily add a zero-size struct for each mode if you don't want to do all the mode definitions inline with the function, which just implements some trait that holds methods for the correct type. Lots of ways to go about it really (though thinking about it, using a trait object might not be the worst thing in this particular instance since you want the definitions to be opaque... it becomes problematic when you are forced to use it).

[gchp]

Decided to go with the trait object. If it proves problematic, we can change it. thanks for the feedback!