[UI Framework] [K7] Add KuiToast and KuiGlobalToastList components.

[cjcenizal]

@snide I made a couple changes which deviate from the original design:

1. I moved the colored stripe to the top of the toast, so the status is more apparent. For taller toasts, this is especially helpful, because you can scan for good/bad/whatever toasts by the stripe, and then continue down to read the title and body.

2. I moved the toasts to the right side of the screen so they interfere less with the main content, especially navigation, which is generally on the left.

To-do:

• Test scrolling behavior when toasts dismiss themselves on a timer.

[cjcenizal]

We can use this in other places to give our scroll bars a consistent style.

[snide]

Pretty rad. 😃 Some small stylistic notes, this top part I can clean up, so no worries, just explaining stuff I'd likely change when I go through after.

1. You want your animation to be bottom -> top, which is how they load in the page, and will be more fluid. Right now these appear as full height items from the right -> left so it ends up being more sudden than it should be and is harder to follow the origin order. Follow the direction of the river you're creating for the user -> go up, up, up.
2. The right side is the main content, not the navigation, which is why you're safer putting them on the left side out of people's main viewpoint where it's less likely to get in the way. Think of where a submit button is more likely to be (the primary action of any page). It'll usually be bottom right. Guessing you wanted this on the right because of the scroll problem, so let's solve that issue instead.
3. Top/bottom bordering is less of an issue and mostly subjective, but for consistency sake it's preferable to keep them on bottom since it follows the theme (think of how forms have the same bottom underline...etc). It's just a recurring style we're using. We want to follow patterns when we can, but if other people see this different, then I'm flexible here.
4. Don't use vertical rhythm classes / helpers when you mean margin. I'll make an article/textblob wrapper class for you to cover the "Format anything I throw it here scenario". We shouldn't ever have a reason to have a 9px margin on anything, we already have spacing constants (kuiSize...etc), no need to make new calculations off of line-heights derived from them.
5. I'd probably add a fade-out delay on dismiss. Animating out is just as important as animating in. It lets you react to the change.

Functional stuff

1. By default we should probably set a default prop timeout for fade out. It's the most common pattern and we don't want people to need to set it.
2. I think I'd set up a prop for whether these are dismissible (set by default to true). There are going to be some actions (like loading actions) where we don't want them to dismiss them until Kibana says its ok to dismiss them.
3. Always try to avoid situations where you have two scroll bars next to each other. They are always clunky. Let's challenge ourselves and see if we can come up with something: what's a better way we could solve this problem? I know it's an edge scenario, but I'd probably start stacking notifications at a certain point rather than using an overflow. Think a stack of post it notes, one on top of the other. Right now as new things come in, they are hidden if a scroll bar exists. If we need to hide stuff, we should probably hide the older stuff, not the newer stuff.

Cool stuff duder. Gonna be a big change over the stuff that gets lost at the top of the page currently.

[snide]

Notes from design meeting....

1. I'm the only one that likes left side, so right side it is. Split decision on the top/bottom bordering. Prolly fine as well.
2. Everyone agreed the scrolling is weird (try to stack) and we should fade out by default.

[uboness]

looks great... would be also great to have a timed-out version of the notification (auto hide after X seconds)... would be interesting if we can utilize the coloured border line to indicate the timeliest (e.g. a "shrinking" line)

[cjcenizal]

@uboness I like that idea too. I think something like that is communicated in the flat design file. I've run out of time on this PR so I'm going to merge now and we can circle back to that idea later.

I'd also like to pause the timeout when the user mouses over the toast, but that'd require building an abstraction around setTimeout which I don't have time for now.