Clarify BidRequest limiting requests to a single venue category (parent, child, or grandchild) about venue-taxonomy

[christiancollins11]

Agree we should update the spec explicitly call out that a screen can have at most one parent, child, and grandchild venue type, and that including some examples would help reduce confusion. Providing an array of venue types is intended to allow buys to easily identify the requesting screen's parent, child, and grandchild venue type (e.g. device.ext.dooh.venuetypelist : [1,101,10101]), so they can apply venue type targeting for each level. The array is not intended to allow screens communicate multiple parent, child, or grandchild venue types. If there are concerns that the taxonomy is not accurately describing a specific venue type, I would suggest proposing an amendment to the taxonomy with the desired venue type + description.

[jayshao]

Notes from #49

• counter-proposal to discard hierarchy, and allow multiple, flat tags
• concerns about fragmenting based on different interpretations, or how to interpret
• there may be some benefits to constraining the number of categories - and forcing smaller sub-divisions
• adjacent POI or other metadata could represent multiple categories if we force a single assignment?
• would that be the same spec? or would it be orthogonal?
• one merit of tagging is allowing cross-cutting categories
• how complicated should the taxonomy be? When should we rely on other targeting (e.g. PMPs)

Proposal: Clarify spec that the expectation is a given request is only classified against 1 venue (+7, -1)