These modification are not necessarily directly related to the
containing PR, I merely saw them while reviewing the containing PR.

Do the selection in mapStateToProps so the container itself doesn't need to
receive all the props that each overlay needs.

Each overlay is responsible for fetching their own props and for providing a
"needsDisplay" static method wich will be called with the full redux state and
should return true if the overlay needs displaying.

Also eliminate duplicated state keeping: the connection and conference error
states can be fetched from their respective base features.

Prepares for the latest eslint & flow-related npm packages which cause
these errors.

ESLint 4.8.0 discovers a lot of error related to formatting. While I
tried to fix as many of them as possible, a portion of them actually go
against our coding style. In such a case, I've disabled the indent rule
which effectively leaves it as it was before ESLint 4.8.0.

Additionally, remove jshint because it's becoming a nuisance with its
lack of understanding of ES2015+.

Prepare for React 16.

The functions need not return anything, or it will be dispatched as another
action.

Rewrite the non-React RingOverlay into the React Component CallOverlay
in a way which makes it easier to port to React Native.

We seemed to be using the names "film strip" and "filmstrip" (and,
consequently, their source code-conscious forms such as film-strip,
FilmStrip, etc.) In order to comply with our coding style which requires
a consistent one name for a given abstraction, choose one name and
rename the uses of the other name.

Wikipedia has a definition of a "filmstrip", I couldn't find a "film
strip". I guess our abstraction can be seen as what's described there.
When I google "film strip", I get results about "filmstrip" at the top.
That's why I chose "filmstrip".

Certain uses of "film strip" such as interfaceConfig.filmStripOnly and
in the external API I left untouched in an attempt to preserve
compatibility.

I wasn't sure whether CSS was tangled in compatibility so I made a
choice and renamed there was well.

In this case makes more sense to have overlay frame included in every overlay instead
of abstract class that implements the overlay frame and have to be extended by every
overlay. In addition, mapStateToProps isn't working well with inheritance.

Split language detectors to be web/native dependent. Take care of strings that contain html.