Design problem: Windows ANSI features aren't enabled by default

[ErichDonGubler]

I've noticed that there will likely be a design problem that needs to be resolved before we can actually get an initial PR submitted upstream: ANSI escape code handling is NOT enabled by default on Windows terminals, which means we get to figure out how to balance setting and restoring terminal state in order to support most features that termion has. The following is mostly adapted from my response to the debut of crossterm on Reddit.

Enabling ANSI support on Windows terminals can conceptually be viewed the same as using a raw terminal -- you're changing core terminal state and it really should be reverted back (i.e., ANSI gets disabled if it wasn't enabled before) once an application is cleaning up. Termion currently handles raw mode by representing it as a struct that will restore terminal state flags to their original values when it gets dropped. It wouldn't be very different to simply enforce terminal I/O to likewise use a struct, but most examples actually just use println!.

I've thought of the following approaches:

• Expose the entire library API through a struct (i.e., Terminal) that stores the terminal state on init and then restores it when destroyed. This seems the most workable, but actually seems like it'd actually add a non-trivial amount of complexity to client code. I don't know what impact it would having on multithreaded code, for instance.
• By convention, use a struct like in #1, but only use it to set and reset terminal state, and allow the rest of the API to be used with free functions. Remember that the motivation for this struct in the first place would be to support Windows-specific behavior, which then seems to defeat the purpose of a cross-platform library in the first place. This doesn't seem like a good solution at first blush.
• Ensure that the ANSI support in Windows terminals is enabled with checks on each API call. This sounds like a bad solution all around: performance penalty with each API call, and no clear way to clean up the terminal state afterwards.

@ticki, I'm hoping that you'll have some input here as which strategy(ies) a PR adding Windows support could realistically employ for termion. I would say that the first option is the best, since it would enforce truly cross-platform code being written the first time, but it's not backwards-compatible, and it will definitely complicate client code.

[ErichDonGubler]

I've chatted @ticki on Reddit, and he believes that option #1 (putting appropriate API surface behind a struct used to initialize terminal state) will be the cleanest and therefore the most acceptable. What's left is to implement this -- I'll make another issue for the implementation of this new design, which we can probably postpone until a later stage in Windows support.