[Feature]: winapp init should be a little smarter when figuring out what project to focus on

### Is your feature request related to a problem? Please describe. When I init in a general folder where the project doesn't live init just creates the files no matter what. ### Describe the solution you'd like init should be smarter about finding well known project types like csproj or sln before deciding to place files. ## Proposed Spec Possible flow: 1. On init run, winapp CLI will detect if a compatible framework lives in the passed directory. For each of our supported frameworks we can check via: - **Tauri:** `tauri.conf.json` at one level below the root - **Rust:** `Cargo.toml` at the root - **Electron:** Parsing `package.json` for electron dependency - **CPP:** `CMakeLists.txt` at root - **Flutter:** `pubspec.yaml` at project root - **Dotnet:** `.csproj` at project root Kick all these off in parallel and return on the first positive result? **Questions: for this step:** - Do we want to detect specific Dotnet project types for enhanced output on the next step? - We don't support other C++ build systems besides CMake or do we? 2. If a project type is detected, we can improve the initial init output with something like: `Tauri application detected. Starting init process..." **Questions for this step:** - While we are it, I know we talked about some of the init prompts not being relevant to certain projects, should we take this as a chance to adjust what we show users? 3. If no project is detected, we have two options: * Fail quickly with an informative error: `We did not detect a compatible development framework in the input directory.` * Allow to init anyway via a prompt with a *verbose* message explaining that most things won't work. Would they have a reason to do this?