feat: read `vim.opt.listchars` for the default config about visual-whitespace.nvim

[mcauley-penney]

I'm open to this, and have something really basic already implemented for it, but I'll have to think about it a bit more. I don't want to force users into it so it would definitely be opt-in.

It is simple for eol but there are multiple types of space and tab listchars.

To adhere to listchars strictly, I'll have to check how many spaces there are and where they are at in the line, given that listchars affords space, lead, trail, multispace, leadmultispace.

If the file uses tabs, the plugin will have to deal with the fact that tabs and the tab listchars have flexible lengths, such as with tab:xy and tab:xyz. I'll have to check at least the tabstop length, get the tab listchar, then trim it correctly (it is shortened and expanded differently depending on if you give xy or xyz).

If we expect strict adherence to listchars and you have listchars set but don't use each of the ones listed above, it becomes worthless because you have to set options somewhere anyway. If you do use each of the given listchars, you can already see them in visual mode. If we do not expect strict adherence, we then have to choose which listchars to use.

[vollowx]

Thanks for your reply first!

To be honest, I didn't think of the complexity of reading vim.opt.listchars as default config before, as I personally use single-char for each type. Now configurating separated seems to be the better choice.

However, there's another idea: we could only read the listchars if its length is 1, otherwise we just ignore it.