feat: build without proc macros

[chippers]

Warning: This code is incomplete and partially broken. Currently it can run examples (not sure if correctly yet), but tests are completely broken.

This ticket, like #850, is going to be a scratchpad; this time for changing the build code to not rely on proc-macros and to try and implement the ability to create an AsTauriContext both automatically and manually.

Changed so far:

• Deleted tauri-macros.
  • The ideal goal is to have no proc-macros, so it will start off with none. It may be necessary to split the load between proc-macros and codegen like many other crates (e.g. phf).
• New build.rs based builder in tauri::build (incomplete api).
  • Allows generating an AsTauriContext scoped struct that can be passed to AppBuilder so far.
• Examples are moved from tauri/examples/ to examples/ and added to the workspace.
  • Because build.rs is not run in library crates for binaries, it was impossible to have an [[example]] that was able to use code meant for build.rs at build time. Workspace examples still check type correctness during cargo clippy.

Some notes:

Because a build script cannot be run for cargo test of a library without a completely custom harness, the tests are currently completely broken. The following resolutions will be tried in order:

1. Change AsTauriContext to require Send + Sync to allow it to be built as a &'static Config during build.rs and around a manually implemented struct such as struct MyContext(Arc<RwLock<MyData>>); to allow building a context during runtime before AppBuilder::build.
   Benefits: Allows the user to have completely custom context behavior if they wish which might enable some advanced use-cases while still having a simple automatically implemented context available with a build.rs. It also allows for us to build a context during a test setup without relying on a build script (hard for tests in a lib).

2. Implement a function based macro to completely replace the current FromTauriContext derive proc-macro. This macro would have shared architecture with the codegen implementation, and allow the user to decide between using a build.rs and a proc-macro. A proc-macro would enable building an AsTauriContext impl during tests and other cases where having a build script is infeasible.

⚠️ This change will mess up if you keep tauri-apps/examples in this repo's root examples/ crate like that repo expects. Watch out.

[chippers]

A benefit of the build feature in tauri-utils is the new tauri-utils::config::build submodule that utilizes quote::ToTokens to spit out a literal Config instance. This allows us to only parse the config once while building the Context (at build time right now) and to avoid parsing it again in AppBuilder like it currently does.

Here's the $OUT_DIR/tauri-context.rs auto-generated code that is built when building communications so far https://gist.github.com/chippers/f19b5365ff0163f66e2066c0c3b28f41 (formatted and removed the instance of AutoTauriContext{} at the end since it's used as an expression in an include!)

the ToTokens impl code is a bit tedious right now, but simple and effective

[chippers]

as noted in the 32271b2 commit message, e1ce72e is a temporary measure to prevent extra build steps before cargo run --bin api. e1ce72e should be reverted after build files are added to git

[chippers]

okay so this last commit d230b04 was pretty large, with some very extreme, significant changes. It's late so ill probably discuss some decisions made during that commit more later on.

here's a mess of bullet points before i forget:

• I haven't even touched tests, expect things to be broken until i add the next bullet point
• FromTauriContext completely removed with no current replacement. this will be replaced with a function proc-macro that utilizes the tauri-codegen crate to generate the code
• tauri-build now exists and has a tauri-build::build() function that should be a cross-platform alternative handling things like Window Resource files. now, the applications build.rs can be as short as fn main() { tauri_build::build(); }
• tauri-build has a CodegenContext builder for generating an AsTauriContext during build time. only way to generate for now until I add that aforementioned function proc-macro. this functionality is locked behind the codegen feature on the tauri-build crate.
• we no longer need OUT_DIR while generating code, which means that the proc-macro will no longer error if there is no build script for the application project. This was possible by injecting the compressed gzip bytes into the generated code instead of writing it to a file and using include_bytes!. This may have a more adverse effect for large files, but I couldn't really tell the difference between embedded directly and using include_bytes! if there is any. I would like to discuss moving to brotli (BSD-3-clause) crate for compression and decompression for embedded assets, as it can save typically another 10-20% in bytes, which could be significant for compile times (speculation) and faster to decompress during runtime
• api example is still temporarily disabled
• AppBuilder::build return has changed from tauri::Result<App> to App which eliminates the need to .unwrap()/handle errors before App::run
• struct Assets -> EmbeddedAssets and now there is a trait Assets meant to represent retrievable assets. this will be important later when i try to allow runtime, non-'static assets to be used in a AsTauriContext.

@ me on discord if you read through it and have questions

[chippers]

added tauri::generate_tauri_context!() to replace the old FromTauriContext. With this addition, the helloworld works fine using the macro, and cargo test works again with the tests using the new macro. yarn test also works from cli/tauri.js.

I've added back the api example, stripped down like the others, but I ran into console errors about ReferenceError: Can't find variable: cli from bundle.js. I don't have time to look into it right now, and everything else is ready. take a look at it before you merge if you want. The rust code builds fine

With the exception of the API example, this merge is ready as in "it works, and all previous tests pass again", but not release ready. I plan to refine the newly exposed crates, APIs, and codegen error messages in future pull requests before release

I'll be a bit busy today, but @ me on discord for any questions, but this should be merge ready keeping the previous information in mind

[chippers]

The checks should all pass now, and the api example is building and running again