Touch feedback manifests in some ugly black border bleeding out of the thumbnail
itself. Since we already provide feedback (be that by adding the blue border in
case of pinning, or showing the menu in case of long press) the perception is
the same, without the graphical glitch.

* feat(tile-view): initial implementation for mobile

- Create a tile view component for displaying thumbnails in a
  two-dimensional grid.
- Update the existing TileViewButton so it shows a label in the
  overflow menu.
- Modify conference so it can display TileView while hiding
  Filmstrip.
- Modify Thumbnail so its width/height can be set and to prevent
  pinning while in tile view mode.

* use style array for thumbnail styles

* change ternary to math.min for expressiveness

* use dimensiondetector

* pass explicit disableTint prop

* use makeAspectRatioAware instead of aspectRatio prop

* update docs

* fix docs again (fix laziest copy/paste job I've ever done)

* large-video: rename onPress prop to onClick

* change forEach to for...of

* use truthy check fallthrough logic instead of explicit if

* put tile view button second to last in menu

* move spacer to a constant

* the magical incantation to make flow shut up

Contributing all buttons in one place goes against the designs that we
set out at the beginning of the project's rewrite and that multiple of
us have been following since then.

Flow caught an incorrect function call.

When in PiP mode the LargeView will not be large enough to hold the avatar (for
those interested in the details, our avatar's size is 200, and in PiP mode the
app is resized to about 150).

In order to solve it, this PR refactors how the avatar style is passed along,
reducing it to a single "size" prop. With this only prop, the Avatar compononent
will compute the width, height and borderRadius, plus deal with some Android
shenanigans.

In addition, the LargeView component now uses DimensionsDetector to check its
own size and adjust the size prop passed to the Avatar component as needed.

Prepare for React 16.

Also move (native) avatar style to film-strip styles, since  that's where it
applies. This is analogous to how the large-view avatar is styled.

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.

Until we make a decision on access modifier hints and adopt a respective
coding style, consistency is king.

Until we make a decision on access modifier hints and adopt a respective
coding style, consistency is king.

Until we make a decision on access modifier hints and adopt a respective
coding style, consistency is king.

As an intermediate step on the path to merging jitsi-meet and
jitsi-meet-react, import the whole source code of jitsi-meet-react as it
stands at
2f23d98424
i.e. the lastest master at the time of this import. No modifications are
applied to the imported source code in order to preserve a complete
snapshot of it in the repository of jitsi-meet and, thus, facilitate
comparison later on. Consequently, the source code of jitsi-meet and/or
jitsi-meet-react may not work. For example, jitsi-meet's jshint may be
unable to parse jitsi-meet-react's source code.