feature: split Transaction from MessagePayload

[Ma233]

Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes/features)
• Docs have been added / updated (for bug fixes / features)

🔵 What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

This PR moves the message packing and verification logic from MessagePayload to Transaction.
Now, the MessagePayload only works for transferring messages.
This PR also removed the generic type T from the MessagePayload struct since it does not care about the type when transferring and verifying. Instead, the T type was moved to the new method, and the data is serialized immediately upon creating the struct.

🟤 What is the current behavior? (You can also link to an open issue here)

1. The origin_verification field and verification field appear strangely in MessagePayload.
2. When users want to create passing messages, they have to create fake or empty MessageRelay.
3. The generic type T for MessagePayload seems straightforward. And make it harder to be specified.
4. The addr field is ambiguous, you have to understand it from the comments.

pub struct MessagePayload<T> {
    pub data: T,
    pub tx_id: uuid::Uuid,
    pub addr: Did,
    pub relay: MessageRelay,
    pub verification: MessageVerification,
    pub origin_verification: MessageVerification,
}

🟢 What is the new behavior (if this is a feature change)?

The Transaction that is used to hold a verified message can be constructed separately.
Users can create the MessagePayload at a later time when they want to transfer a Transaction.

pub struct Transaction {
    pub destination: Did,
    pub tx_id: uuid::Uuid,
    pub data: Vec<u8>,
    pub verification: MessageVerification,
}

pub struct MessagePayload {
    pub transaction: Transaction,
    pub relay: MessageRelay,
    pub verification: MessageVerification,
}

☢️ Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No breaking change.

ℹ️ Other information

Closes #issue

[RyanKung]

LGTM