Improve .resolve behavior

[MichaelHirn]

.resolve, introduced with v0.2.0, fetches class, data, and object assertions (property and assert assertions) for an individual, decodes them, and attaches them to the individual so that they can be accessed via entity.customNameOfTheSchemaAssertion.

Many methods, especially those from higher-level factories like those introduced by rlay-ontology packages, require that individual was resolved first. However, there is no single mechanism to check if an entity is resolved or not, which leads at its best to ugly and non-obvious code. E.g.

if (entity.properties instanceof Object) {
  await entity.resolve()
}

There are also several related issues, such as mental overhead when coding to keep in mind if an entity is resolved at that instance, or in another route run-time overhead when a resolved entity is resolved again, etc.

Solutions

smart resolve

A simple solution would be to add a entity.isResolved() method which is just a nice way to basically do what the non-obvious code from above does. Then update entity.resolve() to only call out to rlay-client if entity.isResolved() is false. This makes calling entity.resolve() cheap reduces boilerplate to a minimum. However, .resolve would need a forceFlag so that a resolve can be triggered when for example the entity has received more assertions in the meantime. This can be limited to only needing to call entity.resolve({force: true}) when an application elsewhere might have asserted something about the entity, by integrating .resolve into .assert. However, this might needs more thought.

ResolvedEntity class

A potentially more elegant solution where any Individual can be cast into a ResolvedIndividualEntity, which must not come with the core rlay-client-lib. Might have similar logic to the first smart resolve proposal. I think smart resolve might be the better way to go here, at least for now, as .resolve is so often used and core.