The implementation was copy-pasted, so it makes more sense to have only a single copy. `HTML5Platform` added a comment about possible future changes, so I kept that. Future changes will still be possible by overriding the function.
Having eight separate implementations made it harder to maintain. While an asset embedding bug got fixed on desktop targets, it got overlooked on others. This lead to assets being included twice on those other targets: once embedded, and once normally. (#1898) Now, that behavior is controlled from one place, and the bug is fixed for eight targets at once.
This also standardizes the case of `asset.embed == true && asset.type == TEMPLATE`. Previously, some targets would prioritze `embed` over `type`, embedding the template into the app without even processing it as a template. Now, it will always prioritize `type`, processing templates as templates and never trying to embed them.
Three targets are left out since they have more complex asset embedding behavior. I haven't checked if the bug is present on any of those.
Code intelligence should always use the newest hxml content, so the fallback mode where the hxml content is generated, instead of loaded from an existing .hxml file, should be used when the project file is newer.
For instance, if the user changes any file/dir paths in their project file, continuing to use the existing .hxml file could lead to confusing error messages that still reference the old/cached file paths. It should always use the latest paths or other values from the project file. It should be considered a bug to use the old cached paths.
Previously, as a workaround, the user would need to clean or build their project again to get updated .hxml files. It might also require restarting their editor/IDE too. Bad developer experience when we can detect this case automatically.