Fix s:hi_normal initialization

[iazel]

Some schema has font=Monospaced 10, but because the regexp doesn't include a space, the 10 will hang around and break the color name -> hex conversion.
Just added a space.

This will resolve issue #67

[nathanaelkane]

I'm unable to replicate the problem that this PR fixes. Are you able to give me more details? Such as:

• Operating System
• GUI Vim or Terminal Vim
• Vim version
• Colorscheme
• Link to your dotfiles (if possible)

When I put hi Normal font=Monospaced 10 into my vimrc it gives me the following error upon opening Vim:

Error detected while processing /home/vagrant/.vimrc:
line    3:
E416: missing equal sign: 10

Wrapping in single quotes seems to work on Windows, but it replaces all the spaces with underscores.

I'd like to merge this in, but I'd like to replicate the problem first. :)

[iazel]

To be totally honest, now I can't reproduce it either! I've upgraded vim since the commit, maybe something change. I use GVim on Ubuntu, with the desert color scheme.

Take in consideration that many other experienced the same issue.

[nathanaelkane]

All good, I'll try some older versions of Vim on Ubuntu.

Either way, it's exposed another bug with that font= regex on Windows.

[alerque]

I am also unable to replicate this bug, but having looked at the situation there would a problem with allowing spaces as per this PR. The font name can certainly include spaces, but in order to do so the string would need to be escaped somehow because the other segments in s:hi_normal are space separated. Unless we know that this value would always be last, I don't think this regex would work without being too greedy.

I'm happy to review this situation if anybody has more info, a working case to replicate the bug, or whatever feedback. In the mean time I'm marking this as draft because it's not actionable in this form.

[alerque]

This would be too greedy because other segments are space separated.
A proper match (if such a thing is even still needed at all) wourd need to
account for whatever quoting or escaping is used in this value. Since
I don't have a working test case I can't say what that needs to be.

[alerque]

It seems like this is related to #38 as well.