Never violate the following rules:

Make the code work with the .hxml based workflow
don't use compiletime #if lime or #if openfl as this relies on the openfl and lime build system. We don't use their buildsystems but try to do the same thing they do for the hxcpp based targets. (Native Windows/ Linux compilation)
Adhere to the spec outlined in OpenFL_Build_Chain_Asset_System_Deep_dive.md and IMPORTANT_INSTRUCTIONS.md
There is sample code in the Export/haxe directory. We want our own src/ManifestResources.hx to mirror the implementation in Export/haxe/ManifestResources.hx
Mirror preload logic from the Export/haxe directory into our own files.
We also want to preload our assets using a similar approach using the ManifestResource and doing related initialization in ApplicationMain.hx

Implementation details:

macros/AssetMacro.hx
- Implement a @:assets decorator that allows specifying assets with the same parameters that openfl/lime use in project.xml
- These assets will be defined in Assets.hx
- Generate an asset manifest default.json in a folder manifest in the hxcpp output directory (the same path the built binary gets put into) (get the path for this from the haxe compiler at build time) as defined with the -cpp flag in build.hxml
- Copy assets into the hxcpp output directory similarly to how lime and openfl do this
Assets.hx
- as stated previously, the @:asset decorator will be used here to specify assets for the compiler to copy to the build output directory at compile time
Main.hx
- This is the entrypoint for game specific code, no need to touch this yet.
ApplicationMain.hx
- This is the actual entrypoint of the application. This sets up the lime/openfl application, window and stage. Also this is responsible for preloading assets.
ManifestResources.hx
- This will be left the same as the sample in Export/haxe/ManifestResources.hx