add webfont resource files for Libertine font family
add config option and styles for Libertine font family
avoid over-riding font family preference if the font has good glyph support
reduce font size boost for Hebrew from 1.5em to 1.2em

The 150% size increase is excessive and makes usage impractical with
several columns open. 1.2 is a more usable default value and works out
so that Hebrew versions take up about the same about of vertical space
as other languages for the same verse range.
Merge remote-tracking branch 'origin/typography-libertine' into test
Re-ordering files more appropriately in order to split up CSS / JS
Modularizing all CSS into separate files.
moving font definitions to separate file
Split up and reorganized code

Conflicts:
	app/css/bible.css
Cleanup references to CSS images. The relative paths are removed by the builder.js script
Font size and family are now configuration options
fixed a few links to images

(adapted from 526f8a0 to preserve fixes after fixing old merge)

Conflicts:
	app/css/bible.css
fix :hover issue
removing unnecessary code
updating version to represent changes
fix pseudo-selector parsing error in 9884e1a

I goofed in my CSS tidy commit 9884e1a by applying a rule for formatting
CSS properties globally to pseudo-selectors as well. This roll-back
should fix all instances of that and is a more complete replacement for
John's partial fix in 81a96ad. Fixed using:

    find ./ -iname '*.css' -execdir sed '/{$/s/: /:/g' -i {} \;
More CSSTidy fixes
fix CSS parse errors and work around IE bug

A couple of these lines just had bad syntax (missing colons). The rest
of this is white spaces fixes that technically should not be necessary
as the syntax is correct per spec, but IE 7-9 has an issue parsing it.
As IE9 is supported by jQuery 2 and hence technically by this app, I've
accommodated it by giving it the value it can read.
remove English strings from language names

Having this string is un-necessary in the case of the default English UI
(if you don't recognize the name of the language, content in that
language is not going to be very useful to you) and outright dead-weight
in the context of a localized UI (if you are using a not-English
version, non-localized strings hard coded in English are not that
useful).

Unless we include a full language name matrix with each language name
localized in each of the languages the site can be localized, it is more
generally useful to just show languages using their localized names (not to
mention easier).

Looking around at major platforms with localization support, this
appears to be the norm now (as opposed to a few years ago when
localization was first rolling out to a few programs and was being
driven by and English-first mindset).

If anything needs a hard-code English fall-back for people to "escape"
from a language they do not understand it would be the name of the
setting and the widget itself. Once they find the widget, having
"English" as a value in the list is enough.
strip hard coded English strings from text indexes