Update Section 5 to include both product and merchant reviews

[alejandro-runner]

This approach uses the same kind for both product and merchant reviews allowing for the mandatory d tag to point to either an addressable tag representing the product "a:30402:<merchant-pubkey>:<product-d-tag>" or a profile tag representing the merchant ["p", "<merchant-pubkey>"].

Having the same kind for both makes it easy for buyers to find relevant reviews.

[ericfj2140]

i think the approach makes sense, keeping it in the same kind

some things to consider for the devs here:

1. should we have additional a/p tags so we're not just parsing d for our filter? (future interoperability)
2. are there scenarios we should consider where a new kind makes more sense?

different relay policies where merchants are retained longer than products ?
future more specific schema changes differentiating merchant vs product? (i don't think so for our use case)

[ericfj2140]

two concerns to address :

1. text and examples currently disagree (p: vs malformed tag syntax)

2. overloading d alone forces clients to parse string prefixes to distinguish product vs merchant reviews. Recommend keeping d as the canonical pointer, but allowing an explicit p tag for merchant reviews (and optionally a for product reviews) as a non-required ergonomic hint.

[pats2sats]

I would recommend p for merchant review, optional a for product review, d tag is a trade ID.
If you buy a product multiple times, don't you get to leave multiple reviews?