dioxus full stack hotreload fails with custom target dir

[LuckyTurtleDev]

Problem If you use a custom target dir. The hot reload fails for dioxus full stack.

Steps To Reproduce

Steps to reproduce the behavior:

create ~/.cargo/config.toml with the following content

[build]
target-dir = ".cache/cargo_target_dir"

❯ dx new
✔ 🤷   Which sub-template should be expanded? · Fullstack
🤷   Project Name: dx-fullstack
✔ 🤷   Should the application use the Dioxus router? · true
✔ 🤷   How do you want to create CSS? · Vanilla

❯ cd dx-fullstack/

❯ dx serve --hot-reload

Dioxus @ v0.5.4 [16:17:50]

    > Hot Reload Mode: RSX
    > Watching: [ src, assets, Cargo.toml, Dioxus.toml ]
    > Custom index.html: None
    > Serve index.html on 404: True

    > Build Features: [ server ]
    > Build Profile: Debug
    > Build took: 282 millis

Listening on 127.0.0.1:8080
| ⚙️ Compiling registry+https://github.com/rust-lang/crates.io-index#unicode-ident@1.0.12                                                                                                                             warning: unused import: `info`
 --> src/main.rs:4:15
  |
4 | use tracing::{info, Level};
  |               ^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

2024-06-12T14:17:53.338422Z  INFO dioxus_fullstack::render: Rebuilding vdom
2024-06-12T14:17:53.338497Z  INFO dioxus_fullstack::render: Suspense resolved
spinning up hot reloading
hot reloading ready
🔥 Hot Reload WebSocket connected
🔮 Finding updates since last compile...
finished
😳 Hot Reload WebSocket disconnected

sometimes you need to perform a change at the code to trigger this issue.

Expected behavior keep hot reload working?

Environment:

• Dioxus version: [0.5.1]
• Rust version: [rustc 1.78.0 (9b00956e5 2024-04-29)]
• OS info: [ Arch Linux]
• App platform: [full-stack]

Questionnaire

• [ ] I'm interested in fixing this myself but don't know where to start
• [ ] I would like to fix and I have a solution
• [ ] I don't have time to fix this right now, but maybe later

[ealmloff]

We currently hardcode the target directory in a few places in the CLI and hot reloading crates. We should read the cargo config instead

[jkelleyrtp]

Talked about it - solution here is to properly use cargo's profiles mechanism to 1) allow parallel builds without our own custom target dir 2) not clobber rust flags 3) expose our own optimization flags

I split this issue out to #2780

[jkelleyrtp]

We now use profiles in #2862 and no longer set a custom out dir.

Of course, if you're merging target dirs you're just gonna have a bad time due to a ton of reasons, but now at least we respect your target dir.