Rethinking the API

# Background/motivation

When doing the changes from version `0.1` to `0.2`, I found out, it's impossible to do a perfect semver trick due to inherent methods on structs. Further, it occurred to me that there are displays with more segments (I think 11) or other kinds of displays and it might be a good idea to be abe to treat them the same (using a trait). Finally, we will probably add `Symbol` type. Historically, we changed the API to support hex and we will probably add `-` sign too. It'd be nice if we have a backwards-compatible way to add new symbols.

# Proposal

Create embedded-hal-like crate:

```rust
trait DisplaySymbol {
type Error;
fn display_symbol(symbol: Symbol) -> Result<(), Self::Error>;
}

// Optionally some helpers that can be used for symbols:
struct DecDigit(u8);
struct HexDigit(u8);
enum MaybeBlank {
Visible(S),
Blank,
}
struct MinusSign;
struct DotAfter(S);
```

This trait allows for great flexibility in terms of upgrading the crate.

# Reasoning

* Why not fixed symbol: ability to statically check if particular implementation supports certain symbols
* Why not associated type: an implementation can more easily upgrade the symbol type or support multiple symbol types.
* Why call it `DisplaySymbol` as opposed to `Display` - more clear and doesn't get confused with `fmt::Display`
* Why multiple helper types instead of a single enum: enables statically checking the supported symbols.

# See also

* [Semver trick](https://github.com/dtolnay/semver-trick)
* Branch `0.1.1`
* #5

Start with the API proposal in this issue, then review branch 0.1.1 and issue #5 for the existing compatibility context. Compare the proposed DisplaySymbol trait and helper types with the current crate API; done means an agreed design and corresponding implementation plan for supporting new symbol types without breaking existing users.

Written by the indexing model from the issue text.