Adds toolbarAdditionalControls prop to EuiDataGrid

[snide]

Summary

Crosses off a line item from #2504

Added a new prop toolbarVisibility.additionalControls which accepts a ReactNode for placing extra buttons within the toolbar. I put these in between the current controls and the full screen for a couple reasons.

1. The area to the left of the controls will be reserved for eventually adding the selection / action button.
2. I'd like full screen to always remain on the right, and I'm possibly thinking of making it a simple icon that is right floated to the corner.

Questions

I briefly considered making a component for these buttons, but really all they do is add a class on top of EuiButtonEmpty and i felt like making a shim component for that reason alone seemed like overkill, though if people think that's a good idea to abstract away the css class I can do that.

Checklist

• Checked in dark mode
• Checked in mobile
• Checked in IE11 and Firefox
• Props have proper autodocs
• Added documentation examples
• Added or updated jest tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

[chandlerprall]

I wonder if we should merge toolbarVisibility and toolbarAdditionalControls. A single toolbar prop that takes boolean | object to allow disabling, enabling (default), and configuring the [visible] toolbar.

(otherwise this PR LGTM)

[snide]

@chandlerprall I think that would be elegant. The only downside I can think to that proposal would be:

1. Certainly more complicated / involved, with likely a lot of moving parts. The prop would accept an array of objects, some of which would be there by default and unchangeable, others would be custom with passed in renders.
2. Ordering would become less known, and that level of flexibility could lead to people building somewhat different experiences, vs having a set default with a set order + additions.

I think I'd likely need a session to figure out how to handle the typing for something like that if we wanted to go in that direction. I'm personally indifferent from the application perspective, so i'll leave it to you for the call.

[chandlerprall]

Not sure we're envisioning the prop the same way,

toolbar={true} // show toolbar with default configuration (default)
toolbar={false} // disabled
toolbar={{
  additionalControls: <Fragment>...</Fragment>
}}

[snide]

@chandlerprall Ahhhh. I got you. Thats much easier. I can do that and think that's a good idea!

[snide]

@chandlerprall Changes made. I kept the toolbarVisibility prop name though because I didn't think it deviated enough in function to make a breaking change to the API.

[chandlerprall]

Got a PR for you on the typescript side of things, to make the helper utility's return type more explicit. snide#10

[chandlerprall]

Changes LGTM; tested locally