Alter layout engine to conform closer to W3C spec

The primary goals of this change are:
  - Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/)
    and a clear articulation of the areas where it deviates from the spec.
  - Support for flex-shrink.
  - Conformance with layout effects of "overflow: hidden".

Specifically, here are the limitations of this implementation as compared to the W3C
flexbox standard (this is also documented in Layout.js):
  - Display property is always assumed to be 'flex' except for Text nodes, which
    are assumed to be 'inline-flex'.
  - The 'zIndex' property (or any form of z ordering) is not supported. Nodes are
    stacked in document order.
  - The 'order' property is not supported. The order of flex items is always defined
    by document order.
  - The 'visibility' property is always assumed to be 'visible'. Values of 'collapse'
    and 'hidden' are not supported.
  - The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The
    rarely-used 'wrap-reverse' is not supported.
  - Rather than allowing arbitrary combinations of flexGrow, flexShrink and
    flexBasis, this algorithm supports only the three most common combinations:
      - flex: 0 is equiavlent to flex: 0 0 auto
      - flex: n (where n is a positive value) is equivalent to flex: n 0 0
      - flex: -1 (or any negative value) is equivalent to flex: 0 1 auto
  - Margins cannot be specified as 'auto'. They must be specified in terms of pixel
    values, and the default value is 0.
  - The 'baseline' value is not supported for alignItems and alignSelf properties.
  - Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be
    specified as pixel values, not as percentages.
  - There is no support for calculation of dimensions based on intrinsic aspect ratios
    (e.g. images).
  - There is no support for forced breaks.
  - It does not support vertical inline directions (top-to-bottom or bottom-to-top text).

And here is how the implementation deviates from the standard (this is also documented in
Layout.js):
  - Section 4.5 of the spec indicates that all flex items have a default minimum
    main size. For text blocks, for example, this is the width of the widest word.
    Calculating the minimum width is expensive, so we forego it and assume a default
    minimum main size of 0.
  - Min/Max sizes in the main axis are not honored when resolving flexible lengths.
  - The spec indicates that the default value for 'flexDirection' is 'row', but
    the algorithm below assumes a default of 'column'.

README.md

@@ -92,10 +92,19 @@ borderWidth, borderLeftWidth, borderRightWidth, borderTopWidth, borderBottomWidt
 flexDirection | 'column', 'row'
 justifyContent | 'flex-start', 'center', 'flex-end', 'space-between', 'space-around'
 alignItems, alignSelf | 'flex-start', 'center', 'flex-end', 'stretch'
-flex | positive number
+flex | number
 flexWrap | 'wrap', 'nowrap'
 position | 'relative', 'absolute'
+overflow | 'visible', 'hidden'
 
+- Rather than allowing arbitrary combinations of `flex-grow`, `flex-shrink`, and `flex-basis` the implementation only supports a few common combinations expressed as a single number using the `flex` attribute:
+
+  css-layout `flex` value | W3C `flex` short-hand equivalent
+  ---|---
+  n (where n > 0) | n 0 0
+  0 | 0 0 auto
+  -1 | 0 1 auto
+  
 - `inherit` value is not implemented because it's a way to disambiguate between multiple colliding rules. This should be done in a pre-processing step, not in the actual layout algorithm.
 
 
@@ -118,6 +127,7 @@ div, span {
   border: 0 solid black;
   margin: 0;
   padding: 0;
+  min-width: 0;
 }
 ```