Keep track of created states

[1inguini]

Keeping track of created state to clean them afterwards is tedious, so why not make AacFlBase keep track of them?
Having mutable state in AacFlBase class might have some consequences of unintuitive behavior, so this feature might need some discussion.

[hai-vr]

AAC is not meant to hold state (and nor return state) between different creation/deletion stages, it is an object that is meant to be instantiated and discarded immediately after it has been used, not kept around in memory nor across sessions.

Any mutability and state management should be done by the consumer of the library, not by the library itself.
A very old iteration of AAC around 6 months did manage a limited amount of state because AAC used to force the use of components, but I took the decision that all of these component/state concerns should not be part of the API since there are a variety of ways AAC can be used.

One such case is that AAC can be executed multiple times in a row to target different avatar descriptors, so the lack of state benefits that case.

This is the reason why AacExample is a separate module, it is a convenient example implementation but not the only one, and this AacExample can be reimplemented by the user to hold state without touching the API.