Handle StepEntityMetadata with matching _types but non-matching other properties

[ndowmon]

For entities specifically, we should somehow handle cases where StepEntityMetadata entities have partially matching properties.

Given a situation where two entities have the same _type but different properties:

const step1 = {
  ...
  entities: [{
    _type: 'azure_database_service',
	_class: 'Database',
	resourceName: 'Database Service',
  }],
  ...
};

const step2 = {
  ...
  entities: [{
    _type: 'azure_database_service',
	_class: 'Service',
	resourceName: 'Database Service',
  }],
  ...
};

The following reflects the generated entities, although only one of the rows would actually be generated.

| Resources        | Entity `_type`           | Entity `_class` |
| ---------------- | ------------------------ | --------------- |
| Database Service | `azure_database_service` | `Database`      |
| Database Service | `azure_database_service` | `Service`       |

One possible way to handle this is to throw in j1-integration document, so actual execution doesn't fail but develpers can see failures before any new commits are added to a graph-<provider> project (because of the husky pre-commit hook yarn j1-integration document).

Related to #309

[austinkelleher]

Perhaps we should consider merging if _class has different values, but throw if any other properties are different (besides _type). In the above docs, I would expect:

| Resources        | Entity `_type`           | Entity `_class`       |
| ---------------- | ------------------------ | --------------------- |
| Database Service | `azure_database_service` | `Database`, `Service` |

[ndowmon]

Idk... in this example, the category enum (["software","platform","infrastructure","physical","other"]) is required on azure_database_service entities that have _class === 'Service', but not on entities that have _class === 'Database'. Would be the case with any other required properties as well (or even non-required properties that are type guarded).

ATM, I'm of the belief that the schema should be consistent across any azure_database_service. But maybe there are arguments against that.

[aiwilliams]

ATM, I'm of the belief that the schema should be consistent across any azure_database_service. But maybe there are arguments against that.

I agree, I cannot think of any case where an entity has a different schema for a single value of _type. The _type: string & _class: string[] are tightly coupled in my mind. Many _type values exist for a specific value of _class, but there is only one _class value for a _type.