Two reasons:
1. This is how it always worked in practice. The old special case actually did nothing due to an oversight.
2. Per the principle of least astonishment, Lime should avoid messing with the user's assets. If they wanted it to be a template, they would have specified `type="template"`.
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.
The old code appeared to be trying to do this, but it didn't work. When it found appinfo.json, it would call `copyAsset()` with an extra `context` argument, which is what you do for templates. However, `copyAsset()` only processes templates when `type == TEMPLATE`, otherwise it ignores the extra argument and processes it as a normal asset.
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.
