Relationship API is unfriendly to Entity-like newtypes

## What problem does this solve or what need does it fill?

Earlier I opened a similar issue regarding events: #21384
With [PR 21408](https://github.com/bevyengine/bevy/pull/21408) attempting to fix the issue for entity events, I want to apply similar changes to the relationship API.

Current problems:
1. The current implementation of `derive_relationship` again makes hard assumptions about the underlying field being exactly an entity and nothing else. Similar to `EntityEvent`, `Relationship::get` this should work with an `ContainsEntity` type.
2. Similar to mutable vs. immutable events discussed in the PR, relationships should be immutable by default. As far as I can tell, the mutability is only required for the "fancy" relationships constructors like `EntityCommands::with_related` or `RelatedSpawner`. I see no downside to disallow these functions in exchange for ensuring the relationship component is immutable.
3. As is, `RelationshipSourceCollection` cannot be implemented for containers of entitoids (i.e. `Vec>`).
- This is a much harder problem to solve. There is just no way to block collection mutation and keep relationships functional. I'm ok living with this, but I just wanted to raise the issue in case anyone has ideas.

## What solution would you like?

I would like to solve at least problems 1 and 2.

1. `derive_relationship` can easily use `ContainsEntity::entity(self.#relationship_field)` to support entitoids
2. We could break out `from` and `set_risky` from `Relationship` into a `SetRelationship` trait and require it for the fancier setup functions. We could then derive this trait only if `#[relationship(mutable)]` is specified (or maybe if `#[component(immutable)]` is NOT specified)

## What alternative(s) have you considered?

N/A