Make yew's #[derive(..)] macros re-exportable.

[AgarwalPragy]

Describe the feature you'd like

Consider the following structure of nested crates common to a project:

project/
 | --- common/
 | --- feature1/
 | --- feature2/

The common crate re-exports yew for feature crates to use

// project/common/src/lib.rs
pub use yew;

# project/common/Cargo.toml
[dependencies]
yew = "0.17.2"

The features crates use yew via the common crate:

// project/feature1/src/lib.rs
use common::yew::prelude::*;

#[derive(Properties, Clone)]
pub struct Props;

# project/feature1/Cargo.toml
[dependencies]
common = {path="../common"}

Current behavior:
The re-exported derive macros (#[derive(Properties)]) don't work, unless the feature crates explicitly include yew in their respective Cargo.toml

14 | #[derive(Properties, Clone)]
   |          ^^^^^^^^^^ could not find `yew` in `{{root}}`

---

Additional Context

I encoutered the same behavior of re-exporting not working with serde::{Deserialize, Serialize} (serde-rs/serde#1465)

From discord chat

Simon: This doesn't work because the generated code needs to use members of the Yew crate. There's no way around that...
Teymour: It would be technically possible to get around this, but probably not worth it.
Simon: This could only work if you could somehow rewrite the generated code to depend on mindwiki_core::yew instead of yew
Teymour: We could use a compile-time environment variable to optionally set a custom prefix to use instead of yew but it seems like a lot of extra cruft to introduce.
Simon I'm like 99% sure this would violate at least 3 invariants xD
Pragy: @siku2 won't that be possible by doing crate::?
Simon: It might work but Span::mixed_site has only just hit stable in 1.45 so we aren't using it yet. If you open an issue for this I will look into it some more