Refactor(tauri): move tauri-api and tauri-updater to tauri

[chippers]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• New Binding Issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes. Issue #___
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
Motivated by 3 things:

1. Simple -> Expand

   • If we start with api as a module in the beta, we are free to expand to a separate crate in the future without it being a breaking change. We cannot go from tauri-api -> mod api however since some projects may have an explicit dependency on the tauri-api crate. Having the option to go either way seems the best as we see how ergonomic it can be in the future.

2. Easier to keep track of and reduce transitive dependencies.

   • We have close to ~400 transitive dependencies. This makes it a bit easier to try and reduce dependency usage by having everything in once place. This is something I want to explore in the future since the current high dependency count creates a lot of linker time. Not only straight up removing dependencies, but also having cleaner separation between them and features.

3. Easier to keep versions in sync

   • Not only for publishing, but it makes it harder for someone to accidentally upgrade tauri while having an un-upgraded version of tauri-api if they happen to have both in their manifest. (and vice versa).

---

Why is tauri-utils not included?

1. We need to use items from it inside tauri-build/tauri-codegen/tauri-macros. Since this would create a circular dependency, we keep it split.
2. In the future I want to expand the config functionality to include items the rust cli needs, and have it depend on tauri-utils.

In short, tauri-utils can be thought of as "Tauri specific things that are useful outside of the actual application". Currently this is basically the config parser/(de)serializer/token builder and the asset key parser. They are very specific to Tauri, but their output is useful in more places than just inside the application. Sometimes called tauri-common by a lot of crates, but utils means basically the same thing and we already have it published.

---

This was kept as non-changing as possible because it's already a 1500 line diff. I think the items exported right now are probably fine, as it's basically what it was before - although maybe we refine it in the future. Also, I think some type aliases exported at the crate root like ApiError and UpdaterError are useful instead of having crate::Error, crate::api::Error, crate::updater::Error. It's currently mostly readable but adding those aliases in the future wont be a breaking change :)

This is something I wanted to explore the benefits of, so I figured I would PR it so it wasn't some "maybe" thing.

[lucasfernog]

We currently have a pending feature request to compile the tauri-api crate to WASM so yew users can easily access the Tauri APIs. This PR complicates that, but one can argue that yew is a very niche use case.

[chippers]

We currently have a pending feature request to compile the tauri-api crate to WASM so yew users can easily access the Tauri APIs. This PR complicates that, but one can argue that yew is a very niche use case.

That's an interesting use case, but I don't think this will complicate it any more than it would need to be at that point anyways. We currently do a lot of I/O and some threading in the api, so we would effectively need to write another backend for it. Maybe when the time comes, the I/O agnostic api could be moved back out into tauri-api and the tauri::api module could stay as it is right now, taking paths and ect. The current api module would be basically a shim of IO over the lower level api, which might fit better in a different crate at that point