fix: inappropriate text wrapping during layout calculation

[nathggns]

In some cases, it seems there was an extra line being inserted during drop cap layout calculation on iOS, as seen below.

I spent quite a long time thinking this was an issue in the layout engine, but eventually ruled that out when I noticed that the height of one of the words going into it was double what it needed to be. When I made the layout text elements appear, I noticed one of the words was wrapping inappropriately, which was throwing off the calculations in the layout engine.

It seems that the defined width on the iOS container, which I believe was added to cancel an iOS optimisation from preventing onLayout from being called, was causing React Native to intermittently attempt to wrap certain words before it gave up. Removing this defined width prevents the inappropriate wrapping, and it also seems we don't need that defined width to ensure onLayout is called.

In terms of the cause of this inappropriate wrapping, I'm not entirely sure what it is, but it seems it could be connected to facebook/react-native#18258

@jmars you may well be particularly interested in this as you may know more about why the defined width was necessary in the first place.

[jimhunty]

Should this be captured in a test?

[nathggns]

@jimhunty as tests don't run onLayout, it's hard to test this package in any meaningful way that would expose this issue. In theory we could run a snapshot test on the styles, but it's not going to test any meaningful part of the package unfortunately.

[coveralls]

Coverage remained the same at 89.393% when pulling 0f6add8 on fix/drop-cap-calc into fc46e55 on master.

[jimhunty]

Sounds like a test approach for this should be considered in future.