Remove sprintf format parsing for Rust lexer

[KamilaBorowska]

Rust doesn't use sprintf parsing for its string formatting, using Python-style formatting instead.

For instance, print!("test %?", a.b) would be written as print!("test {:?}", a.b) in Rust today. The old syntax was removed before 1.0, as such there is no real reason to support it.

[pyrmont]

I need to have a think but I'm a little hesitant. One of the primary uses of Rouge is as a syntax highlighter for Jekyll-based blogs. It'd suck if you had some pre-1.0 code samples on your blog and they were highlighting fine and then suddenly they started having errors.

[KamilaBorowska]

In this case, %-strings will be formatted as normal strings, which doesn't seem too bad. Nothing in the language considers %-strings to be special (although this may not be the case for external libraries, that said from popular libraries, I think it's pretty much just chrono::format::strftime, and this is time formatting, which is going to be wrong with this rule anyway, as it's designed for pre-Rust-1.0-printf-like-interfaces specifically).

That said, I suppose the Rust lexer also supports some pre-1.0 keywords, which are much bigger of a deal (copy, do, fail, log, priv, pure). do and priv are reserved, but the others are valid identifiers in Rust programs. Similarly, there are some pre-1.0 types.

In fact, log somewhat conflicts with a popular Rust library called log, so it may make sense to remove that one. Or I suppose avoid highlighting log as a keyword if it's followed by }, ,, ;, :: or ! (as this pretty much indicates not using old log keyword). Example of incorrect formatting of log: https://gitlab.com/pastebinrun/pastebinrun/blob/master/src/models/paste.rs.

Just to be clear, I'm aware that assert and drop also are no longer keywords, but they exist in some way in a language (assert! is a macro, and drop is a function).

I suppose not merging this is fine, but at the same time, merging this shouldn't affect the old code samples particularly much (sure, you lose highlighting on %, but it's not a big deal, I feel like).

[pyrmont]

@xfix Thanks for the explanation. I agree with you that the fact it'll just be highlighted as part of the regular string limits the adverse impact.

As for the other points, I think those are worthwhile fixes to consider but in a different issue/PR. I'll accept this and merge it in.