Services -> integrations?

Here's a quiz. Is a "service":

- A badge endpoint?
- A subclass of `BaseService?
- A service in the colloquial sense, e.g. PyPI, npm, GitHub?
- All of the above?

The maintainers have discussed offline that this nomenclature is ambiguous.

The word "badge" has a similar problem: is the badge the result, or the code that generates it? I think my favorite of the proposals was @PyvesB' suggestion to adopt the word "integration".

Here are a few related proposals:

1. Rename Base*Service to Base*Integration.
4. Rename all the `.service.js` files to `.integration.js`.
3. In code and documentation, refer to service tests as integration tests. Refer to the existing integration test suite (GitHub and Redis) as _core integration tests_.
1. Shall we rename those existing `*.integration.js` to `*.core-integration-test.js`?
4. Keep the name `services/` for the code tree? Rename the **service-badge** issue label to **services**.
1. Or rename `services/` to `integrations/` and rename **service-badge** to **integrations**.
6. In documentation:
1. Refer to each BaseIntegration (neé BaseService) as an "integration"
2. Adopt the colloquial meaning of "service": GitHub is a service; Travis is a service; npm is a service. We've sometimes called these "service families" in the past. Now they will be called "services."

Thoughts?

Start by reviewing the proposed terminology changes for Base*Service, .service.js files, services/, labels, and documentation. Compare the alternatives in the issue, including integration tests and core integration tests. Done means the maintainers agree on one naming scheme and its affected code, tests, labels, and documentation are updated consistently.

Written by the indexing model from the issue text.