Performance is bad on actor with many skills and skill abilities

[CodeWringer]

Every time a field is updated, the re-render takes up to a second or more. It should be faster than that. This is probably related to the fact that skill abilities are stored in arrays and that the update delta is much larger than it really needs to be.

• [x] Ensure arrays are no longer used for skill abilities. Turn them into properties on the skill document, instead.
• [x] Ensure the delta only comprises of the data to change.
  • Currently, if an object is part of the property path, the entire object is copied. Instead, an empty object should be used as the basis, instead.
• Add a small delay, which is reset upon every value change. Only once this delay has elapsed, send the update.
  • Hopefully, this helps with values changing very rapidly. A prime example of this are the number spinners, which can be 'scrolled'.
• [x] Turns out, FoundryVTT persists everything in the data-property of a document. Therefore, derived data must no longer be added as a property, but rather as a method. The data property must not be polluted with derived data!

[CodeWringer]

Upon current investigation, it appears that the view model system is taking up at least half a second on each render. These times must be reduced.

[CodeWringer]

Upon comparison with other document sheets, it appears only actor sheets take this long to render. And it makes sense they would take longer.

An actor sheet loads all its templates and view models up-front. The more embedded documents there are, the longer this takes. But when changing data on one of the tabs of an actor sheet, for example on a skill document, then the user might not currently be interested in the data on their health tab. It is really unnecessary to load the health tab data right away.

Also, very long lists of skills are to be expected. The number of skills on an actor should not affect the loading quite so much.

The following approaches might help mitigate the perceivable performance problem:

• See #183
• Lazy rendering/loading.
  • This is especially interesting for very long lists of items, such as very long lists of skills. Skills are especially interesting for such a feature, as they're fairly complicated.
  • [x] Lazy actor sheet tab loading.
  • See #184
• [x] View model caching.
  • Ideally, this would eliminate the need to frequently re-instantiate the view models. However, the current system is based entirely on the expectation that view models are re-instantiated upon every render. This means a lot of view models currently rely on current data to be passed to them via their constructor. Instead of the constructor, a new method would have to update data on the view models. This new method would have to be called by the sheet, even before it is rendered. A good point of entry would probably be the getData method of the sheet classes. That is where view models are instantiated, currently.
  • In order to cache the view models, they'll now have to be cached on the game.ambersteel.viewModels property.

[CodeWringer]

See #185