feat(build): support plugins that are defined in app crate

[lucasfernog]

Since the plugin permission management is done at the build script, to support inlined plugins we need to change tauri-build to expose such API. This PR adds a new tauri_build::Attributes::plugin function, where you can use tauri_build::InlinedPlugin to define metadata of the inlined plugin.

Ref https://github.com/tauri-apps/plugins-workspace/issues/928

[amrbashir]

Its DX is weird, but manageable.

Do you think we can make the runtime Plugin builder allow passing its ACL instead of on the build script?

[lucasfernog]

that would be the ideal approach but currently we validate permissions on the build script and resolve the allowed commands during codegen. so there's no runtime cost and no way to set the permissions at runtime

[lucasfernog]

this PR tries it best to match the behavior between inlined plugins and actual plugin crates. I think it's fine as long as the documentation is good on the website, though I wish the tauri-build entry point was better than tauri_build::build(Attributes::new()).

[amrbashir]

yeah, it is not horrible, we can ship this

[songjiachao]

When can I use this feature?

[Quietly-20201113]

Two months have passed, when can I use this feature?

[FabianLars]

This feature was released on Februrary 19 in tauri-build beta.2 (3 days after this pr was merged).

[stickmy]

Some tips here: If the command's name uses snake-case style, such as get_app_setting, you'll get error like ACL: SetPermissionNotFound when you try to put the permissions fields in inline plugin's permission configuration file like below:

[default]
description = """
permissions = ["allow-get_app_setting"]

The correct way is to use kebab-case style in permission configuration file, just like this

[default]
description = """
permissions = ["allow-get-app-setting"]