Update doc comments, Fixes #626
Update type ramp
Toolbar API review updates, overflowMode -> inlineMenu, drawer -> menu
Adding extraClass property to Toolbar to support styling overflow menu
Cache public d.ts locally to avoid dependency problems.
Fix #629
Fallback animation for indeterminate progress. #610
Update package.json

Fixes #571

Also stub out require-json in modular builds.
 AppBar: remove support for .win-reduce
Fix #634: asb: font color of selected result too dark
ContentDialog: Suppress edgy & type to search

Summary of changes:

- ContentDialog
  - Update accent color
  - Add doc comments for DismissalReason
  - Use aria-flowfrom/flowto to cause Narrator to caurosel rather than
    leaving dialog
  - Make ContentDialog more aggressive about eating keys
    - Goal: app hotkeys won't work (e.g. alt+left arrow to trigger the WinJS
      back button) but browser hotkeys will (e.g. ctrl+n for a new browser
      window)
  - Suppress SearchBox's type to search feature while a ContentDialog is
    showing by canceling WinJS.Application's
    beforeRequestingFocusOnKeyboardInput event
  - Suppress edgy while a ContentDialog is showing
- WinJS.Application
  - Add support for stopImmediatePropagation
  - Wrap the edgy WinRT events so that they can be suppressed
  - Wrap the type to search WinRT event (requestingfocusonkeyboardinput)
    so that it can be suppressed
    - Did this as 2 events (beforerequestingfocusonkeyboardinput and
      requestingfocusonkeyboardinput). Mark former as handled to suppress
      the latter. The WinRT requestingfocusonkeyboardinput fires on every
      key press so this was implemented carefully so that
      WinJS.Application only registers for the event if somebody is
      interested in handling it.
- SearchBox implements type to search in JavaScript when the WinRT API
  isn't available. This implementation was moved into WinJS.Application
  and exposed via WinJSApplication's requestingfocusonkeyboardinput event
- SearchBox now consumes WinJS.Application's type to search event instead
  of the WinRT one
- AppBar and Overlay now consume WinJS.Application's edgy events instead
  of the WinRT ones
Update test to test against new value. Closes #624.
Commit for ListView header/footer feature. This commit:
- Adds the ability for a developer to add headers and footers to the ListView via the listHeader and listFooter properties that were added to the ListView
- Adds new CSS classnames and styles for the header and footer container elements
- Adds events for header/footer visibility status updates
- Adds the header and footer to the ListView's keyboarding story
Fixes build break from last checkin
Title: Update List and Grid layouts to use one giant structural node when/if we detect flexbox bugs in the enviornment, in order to enable cross browser support of item striping after edits.

We have changed the scope of item striping to only apply to WinJS list and grid layouts as well as any custom layouts that opt in to using structural nodes by setting Layout.numberOfItemsPerItemsBlock. This checkin changes our List and Grid Layouts behavior when we detect known bugs with nested flexbox scenarios in the browsing enviornment to always use structural nodes, so that those layouts can continue to reparent items into containers whenever edits happen, with reparenting being the prerequisite to preserving item striping after edits without compromising performance.

Normally our List and Grid layouts will put all of the items of a group into several win-itemblocks elements with, each itemsblock containing a handful of items. The itemsblocks are in turn put into a  single win-itemscontainer element which contains all the itemsblocks and items for that group.  Our List and Grid layouts will then make both the itemscontainer element and the itemsblocks elements display:flex.

However some browsers do not display nested flex boxes correctly, and has a result, our layouts when detecting these bugs exists, have had been forgoing itemsblocks entirely, putting all of the win-items directly into the win-itemscontainer, leaving the win-itemscontainer as the only display:flex element.  With this change we now handle bugs with nested flexboxes by putting one giant itemsblock into the itemscontainer element, putting all of the win-items of a group into the single itemsblock, making the itemscontainer display:block, and let the itemsblock element be the display:flex element.
Toolbar/AppBar: Redlines updates
minor css tweaks
Mouse hover state of AppBar ellipsis button is incorrect for high contrast mode, Fixes #526
Enable control over item virtualiztion in ListView: https://github.com/winjs/winjs/issues/577
 The ListView control does not expose any way for developers to control item virtualization. There are many scenarios where developers creating applications that are mostly composed of list experiences desire fine grain control over how items are virtualized.
Started SplitView in TS and JS