Move fields from Buffer into a BufferData struct

[geieredgar]

As noted by others in #39, keeping Buffers around is cumbersome because it borrows FontSystem. This PR tries to solve that by making Buffer a wrapper around a new BufferData struct that contains all data previously owned by Buffer.

Buffer::from_data and Buffer::into_data allow converting between Buffer and BufferData.

Users of Buffer shouldn't need to change anything, because Buffer references are coerced to BufferData references via Deref/DerefMut.

Note: This is only a first step towards better ergonomics, because moving BufferData into Buffer can be itself pretty cumbersome and may require suboptimal code like using Option<BufferData>.
I envision the following steps for a follow-up:

1. Make Buffer borrow BufferData instead of owning it. The idea is that users would always store BufferData instead of Buffer and create a temporary Buffer when they need to work with it.
2. (Optional) If it is desired to keep an owning Buffer, we could instead rename Buffer to OwnedBuffer, and add something like this:

pub struct Buffer<'a> {
    font_system: &'a FontSystem,
    data: &'a mut BufferData,
}

pub trait BufferMethods {
    fn inner(&mut self) -> (&FontSystem, &mut BufferData);

    // Methods of the old Buffer would be moved here, with a default implementation 
    // that operates on the FontSystem and BufferData returned by inner
    ...
}

impl<'a> BufferMethods for Buffer<'a> {
    fn inner(&mut self) -> (&FontSystem, &mut BufferData) {
        (self.font_system, self.data)
    }
}  

impl<'a> BufferMethods for OwnedBuffer<'a> {
    fn inner(&mut self) -> (&FontSystem, &mut BufferData) {
        (self.font_system, &mut self.data)
    }
}

[dhardy]

Is it possible to construct a BufferData without a &FontSystem? That would be the way I would want to use this.

KAS-text has an even lower level decomposition: Text is a "text" + Environment (options) + TextDisplay (runs & glyphs without the source text), though in practice the only use I found for this is being generic over the text (String, &str` or some type of rich text providing formatting markers). The font library is completely excluded (it's a lazy static, and not accessed until the text is "prepared").

[geieredgar]

Not with this PR alone, but I think a possible addition could be adding a flag to BufferData that signals Buffer::from_data to prepare the text.

[geieredgar]

Closing this in favor of #97.