Further clarify proofs of invalid erasure coding

# Summary

The node types section only states who (which node type) is able to _generate_ proofs of invalid erasure coding. Nowhere is explained what happens after generating them. This leaves a lot of room for interpretation. Who should care about those proofs and how will they be propagated (to who)?

> Consumers of fraud proofs would be anyone that just does DAS. I guess that could be made more explicit.

Also, do they trigger slashable events? If yes, who will be slashed?

> In terms of what penalities fraud proofs are associated with, that's more of a consensus/evidence concern.

## Action Items

These should be separate issues that should be handled successively:

- [ ] specify the data structure for these fraud proofs
- [ ] specify the flow of events and the underlying assumptions
- [ ] clarify grace period to light clients to wait for erasure coding fraud proofs and implications for light clients (wait for fraud proofs?)
- [ ] specify penalties / slashing (if any)

related issue about evidence types: https://github.com/lazyledger/lazyledger-specs/issues/23
also related: celestiaorg/celestia-specs#110

Start with the action items in this issue and review the linked evidence-types issue and related celestia-specs issue. Done means the specification covers the fraud-proof data structure, event flow, light-client grace period and implications, and any penalties or slashing.

Written by the indexing model from the issue text.