Remove unexposed functions from declaration files

[markov00]

The generated declaration file eui.d.ts is exposing some utility functions used only for tests like takeMountedSnapshot

declare module '@elastic/eui/src/test/take_mounted_snapshot' {
	import { ReactWrapper } from 'enzyme';
	import { Component } from 'react';
	export const takeMountedSnapshot: (mountedComponent: ReactWrapper<{}, {}, Component<{}, {}, any>>) => ChildNode | null;
}

This requires to declare @types/enzyme in the deps instead of devDeps as you also noticed here: #2828

Do we really need these test utility to be exported as part of the public API?
I’m asking because this dependency can and is creating some resolution conflicts within @elastic/charts because of two different versions of @types/react. I've solved that updating reacts types here and there, but I think it can be also cleanly solved if EUI exposes only its own types.

In elastic-charts we are using to mark the dependencies we don't want in the generated files as @internals and use stripInternals in the tsconfig.json (it's something that at the moment is not documented, I don't have an idea on why it's not on the TS documentation anymore).

Some cleanup can also be possible with the other @types you have moved under deps

@chandlerprall @thompsongl

[thompsongl]

Some background:

Quite a few places in Kibana import from '@elastic/eui/src/test/' (findTestSubject, for the most part), so keeping the types available was the main consideration when deciding to move enzyme to be a dependency (as opposed to removing the exported types).
In reality, I think we see the @types/enzyme dependency for testing utility types as more of a peerDependency. Whereby you can choose to use the testing utilities if your project also uses enzyme/@types/enzyme.

@chandlerprall proposed generating a separate test d.ts file for opt-in test utility use, removing the types from EUI's main d.ts

[thompsongl]

Update: Kibana imports actually target '@elastic/eui/lib/test/' which means that the definitions don't match.
We may still want to create a new d.ts file, but it would be an enhancement and not to maintain compatibility.