Seperate out icon crate

[liuchengxu]

To make the optimization of #353 easier.

[ImmemorConsultrixContrarie]

Why do you keep writing lazy_static hashmap instead of const table? Yeah, map has some indexing hacks, but you can do even better hacks with const tables.

There's no magic in lazy statics and they are good for very few things actually:

1. You need a mutable heap-allocated static. Like static mut MAP: HashMap<_, _> = ...; /* other code */ unsafe { MAP.insert(item); }
2. You need a big allocated thing, that should be static, but is not always necessary for each program's run. Like static INNER_HEAP: Vec<u8> = Vec::with_capacity(1_000_000);
3. You need a big computation that involves heap-allocation, result should be static, and it is not always necessary for each program's run.

That's all. Any other thing could be done with const tables. For example, right now you can do better than hashmap with simple

let icon_index = match CONST_TABLE_EXTENSION.binary_search(extension) {
    Ok(index) => index,
    Err(_) => return DEFAULT_ICON,
};
return EXTENSION_ICONS[icon_index];

if you would break this tuple table into two separate tables, because now they are sorted. And much better than hashmap, if you'd implement intermediate indexing by first letter.

And the last thing I wanted to mention: [char; N] takes much less space (2-5 times less, based on pointer length) than [&str; N], and all you icons are a single char right now.

@liuchengxu

[liuchengxu]

@ImmemorConsultrixContrarie Thanks for the insights. I merely copied from the src/icon.rs without improving such Rust code as I'm not familiar with these hacks, but I do agree with you that it can get much faster. I made this PR so you don't have to duplicate them in #353. And if you are intersted in contining to boost the icon code, this PR can make it easier. I have read the comment you wrote about the icons in #353, I think it's worthy of another standalone PR.