Expose services on public interface

[bevacqua]

Currently we only expose components as part of the public top level interface, this resolves that. This is merely a build issue we have that didn't exist in the ui_framework branch. We can also build on top of this PR to add new exposed functions like the ones discussed in #3, without tainting the component layer.

[pugnascotia]

I started looking at this and compared it with how other packages do their distribution, such as:

• react-bootstrap
• Redux
• React

I realise that where a bundled version of the code is provided, it built with dependencies externalised, so that e.g. React isn't built-in to react-bootstrap. However, that sort of build is only suitable where you're pulling in React into the global scope, e.g. via a CDN into window. For CommonJS usage, these libraries still ship individual, transpiled files.

So a Webpack bundle with React externalised is useful, but not in e.g. Cloud where we're using ES2015 modules throughout. I've therefore re-added the transpiled build step, but I've moved the output to /lib/, and pointed the package's main entrypoint to it. I've also:

• Stopped transpiling *.test.js files
• Moved inline loader config in the docs to the webpack config
• Fixed some broken imports in docs
• Made the single Lodash import be a specific function import, which removes a lot of unused code from the bundle.
• Added a build step to produce a minified bundle as well
• Added dist and lib to .gitignore in anticipation of a proper release - I observed that in the packages above, they don't version their built artefacts in Git.

I noticed that src/components/form/checkbox/_checkbox.scss has a relative URL import to ../src/components/icon/assets/check.svg, which makes it through to the distributed CSS file. That's note going to work in a real app, so I'll look at what to do here. Inlining it automatically would probably be the best thing.

[pugnascotia]

Approving so we can merge and iterate on this.

[bevacqua]

Lovely.