Bubble width fix

[non-descriptive]

Should be good for a lot of cases, like I've presented in #1. Not sure if I wanna fix it for something like ¯\_( ͡° ͜ʖ ͡°)_/¯

[Plecra]

As a rule, the only true source of truth for text sizing is your font renderer... I've been wondering for a while if we can use terminal APIs to get the right behaviour for these alignment tasks.

[Plecra]

Yeah! Awesome :) Rust can ask terminal renderers for true text size with this:

// this leaves `msg` in the text buffer! Make sure it's overwritten if you dont want weirdness
print!("\r{msg}");
std::io::stdout().flush().unwrap();
let count = crossterm::cursor::position().unwrap().0 as usize;
print!("\r");

But there's a side effect of making our test suite much nastier, since we need to give the code a real TTY. unicode-width is a tidier solution in the end!

[Plecra]

Uhoh... that was probably a bit eager. Alacritty seems to get very confused by ligatures. Here it's rendering text at the wrong place in the input buffer. I get the sense things will be even more exciting with various linux terminals :D

marli@Elsie:/$ "¯\_( ͡° ͜ʖ ͡°)_/¯"   more
-bash: ¯\_( ͡° ͜ʖ ͡°)_/¯more: No such file or directory

[non-descriptive]

Yes, alacritty still doesn't support ligatures. And also I'm not sure whether axolotl should support speaking in this kind of emojis, since anyway half of the terminals will not be able to render half of the symbols in it. git bash, cygwin, default cmd, powershell, windows terminal, alacritty - on windows they render it very poorly on average for most smileys like that. Same stands for Z̯̮̦̲͓͇͔A̓̔L̠̦͓̻̩̲ͧ̾̍͝G̸̝ͥ̀̌ͫ̅̊͂O͔͓͔͚̳̫͑!̳͉̹̬͌́ fuckery aka multiple combining characters per symbol, which is basically unused in regular written text. Smiley above do some trickery, combining full-width characters (Japanees/ Chineese regular kanas aka CJK) with normal single width characters and library, I've added, doesn't make much distinction if they are that mixed.