Admin Page: Remove dops-components as dependency

[oskosk]

Brings in all the components, mixins, scss, libraries and dependencies that the Admin Page has been using so far from dops-components.

Current status: Everything builds properly. It's a proposal of course.

Changes proposed in this Pull Request:

• Moves a lot of components from dops-components into _inc/client/components.
• Moves a lot of css from dops-components into _inc/client/scss.
• Moves a few mixins from dops-components into _inc/client/mixins.
• Moves a modules from dops-components into _inc/client/lib.
• Adds some dependencies to package.json.
• Removes webpack building instructions for dops-components.
• Removes dops-components as dependency from package.json and yarn.lock.

Testing instructions:

• Checkout this branch.
• Run tests: yarn test-client.
• Run lint: yarn linst. Expect no errors.
• Build cleaning all dependencies to be sure: yarn distclean && yarn clean-client && yarn cache clean && yarn build.
• Build production version cleaning all dependencies to be sure:

   yarn distclean && yarn clean-client && yarn cache clean && yarn
   NODE_ENV=production yarn build-client
  

• Confirm the Admin Page loads properly.
• Check that the watch task works: yarn watch and the Admin page loads properly.

Why

• It's difficult for some folks to just jump in and add the necessary changes to components for the piece of work they're tackling.
• It's difficult for some folks to have in perspective the other dependants of dops-components in order to be able to contribute to dops-components without breaking the dependants.
• CSS works and builds well currently but we're accumulating different patterns from different epochs and the first argument ^ helps in those not being up to date.
• The complexity of having this dependency has been proven for almost two years now.
• It's hard to make people pay attention to review requests on the dops-components repo.
• Workflow complexity arising from this dependency does not justify the distributed nature of the components on which Jetpack needs to rely.
• It's extremely difficult to be able to cope with JS trends and learned best practices if no one feels committed to full-time maintenance of the dependency.
• Jetpack has some needs for the future that make it quite hard to share the updates needed in dops-components with other dependants that don't have those needs (Compatibility with newer react, with new features of webpack, etc).

[dereksmart]

You hit the nail on the head with the why reasoning behind this. The idea of the separate dependency was well-intentioned, but proved not worth the extra efforts to maintain, especially since it's only us and another product using it.

[dereksmart]

I think we should look at updating the classnames to jetpack- rather than dops-. Probably in a separate PR?

cc @MichaelArestad thoughts?

[MichaelArestad]

I think we should look at updating the classnames to jetpack- rather than dops-. Probably in a separate PR?

@dereksmart Yes. Bingo. That!

[dereksmart]

Tests well, I found no regressions. Let's get this in and tidy up the css classNames in a separate PR

[dereksmart]

Another thought -- We'll want to clean up the imports, switching from external to internal. Can also be handled in another PR