Move to_{html,xhtml,xml,text,json} methods from Page to TextPage

[ginnyTheCat]

This moves to_{html,xhtml,xml,text,json} from Page to TextPage which is more inline with how the C API itself works. This allows specifying the TextPageFlags like PyMuPDF does depending on the format requested when no explicit flags are passed. Ontop this has the added benefit of not having to construct a fz_stext_page twice when calling to_text and to_json for example (very visible in the tests/test_issues.rs file and the examples/).

To fix #69 the code in the issue can now be adapted to:

use std::fs;

use mupdf::{Document, TextPageFlags};

fn main() {
    let doc: Document = Document::open("input.epub").unwrap();

    let page = doc.load_page(7).unwrap();
    let text_page = page.to_text_page(TextPageFlags::PRESERVE_IMAGES).unwrap();
    let html = text_page.to_html(7).unwrap();
    fs::write("out.html", html).unwrap();
}

To fully match PyMuPDF's behaviour here TextPageFlags::PRESERVE_LIGATURES | TextPageFlags::PRESERVE_WHITESPACE | TextPageFlags::CLIP | TextPageFlags::PRESERVE_IMAGES | TextPageFlags::USE_CID_FOR_UNKNOWN_UNICODE would need to be passed. Therefore it might be worth adding either

a) A shortcut function like (this would have the benefit of keeping the Page::to_html function in the same place, even if with slightly changed behaviour). This would fix #69 without a code change for example.

impl Page {
    fn to_html(&self) -> Result<String, Error> {
        self.to_text_page(flags_from_above)?.to_html(self.inner.number)
    }
}

or

b) An alias like TextPageFlags::DISPLAY = flags_from_above (which would prevent people from doing the fz_page -> fz_stext_page conversion more often than they would need to, just because they don't see it hidden inside the Page::to_html function).

I'm unsure myself which one of these would be better, but that's an addition that could come in a future PR anyway.

[messense]

LGTM, just one question.