[EuiInMemoryTable] Replaces search support with more generic toolbar support

[uboness]

• the toolbar still supports search (you can configure a search bar on it)
• you can configure leftTools - tools/actions that will be placed to the left of the search bar (if one exists)
• you can configure rightTools - tools/actions that will be placed ot the right of the search bar

There's a default tool (right & left) that you can configure (either a normal button os an icon button). It provides ootb functionality to determine its availability and state (enabled/disabled) based on the current state of the table (for example, you can make the button available only when something is selected)

It is also possible to provide a custom tool.

Consolidated the notion of a tool between the those added to the toolbar and those added on each row (as part of the actions column). what used to be an item_action is now contextual_action - it's an action that has a certain context - this context is passed to all the action callbacks to determine its availability and state. In the case of an item action, the context is the item, in the case of a toolbar action, the context is an object representing the table.

Closes: #443

[cjcenizal]

Alternatively we could offload the burden of providing tools to the consumer like this:

const toolbar = {
  leftTools: [
    <EuiButton
      iconType="trash"
      color="danger"
      onClick={()=> {
        store.deleteUsers(this.state.selection.map(user => user.id));
      }}
    >
      Delete items
    </EuiButton>
  ],
  /* ... */
};

Personally, I prefer this approach because it reduces the surface area of our API (they're using the components directly, instead of a configuration which maps to components under the hood), reduces complexity of the implementation (which makes debugging and maintenance easier), and increases flexibility (so we can pass new kinds of tools into these areas of the search bar in the future without needed to change the underlying implementation).

What do you see to be the main advantages to your approach, @uboness?

[uboness]

There is a reason for going a different route... Well, actually there are more than just one. But in general there's more than just passing controls to the toolbar... Each control has a context - the table in this case - and that context will determine the state of the control - is it always available or only available under certain circumstances? Is it always enabled? Maybe it has different look (color / icon) depending one the state of the table... You need to be able to capture all this functionality... And just passing the components directly will translate to a whole lot of boilerplate code your example doesn't capture. (Eg only shows the button when something is selected). The implementation captures all of this is a simple interface.

[cjcenizal]

Closing in favor of #458. We'll reopen if the node-based approach becomes too frictionful.