Lite/Full split: eliminate all TODOs from the specification

[Ladicek]

This is an umbrella issue to track the work on eliminating all TODO comments from the CDI specification Asciidoc sources, added in the initial Lite/Full split PR (#470). More sub-issues will be created and this issue will list them (and their status) to provide an overview.

• Lite/Full split: finish preface #490 Lite/Full split: finish preface
• Lite/Full split: define packaging/deployment/lifecycle #483 Lite/Full split: define packaging/deployment/lifecycle
• Lite/Full split: define new extension API #484 Lite/Full split: define new extension API
• Lite/Full split: decide on Portable Extensions mentions in the CDI Lite spec part #485 Lite/Full split: decide on Portable Extensions mentions in the CDI Lite spec part
• Lite/Full split: decide on passivation mentions in the CDI Lite spec part #486 Lite/Full split: decide on passivation mentions in the CDI Lite spec part
• Lite/Full split: decide on other mentions of Full-only concepts in the CDI Lite spec part #489 Lite/Full split: decide on other mentions of Full-only concepts in the CDI Lite spec part
• Lite/Full split: make @Singleton a bean defining annotation? #487 Lite/Full split: make @singleton a bean defining annotation?
• Lite/Full split: does CDI in Java SE environment (SeContainer etc.) have to support Full? #488 Lite/Full split: does CDI in Java SE environment (SeContainer etc.) have to support Full?
• Lite/Full split: decide on "Inter-module injection in CDI Full" #491 Lite/Full split: decide on "Inter-module injection in CDI Full"
• Lite/Full split: decide on "Unsatisfied and ambiguous dependencies" #492 Lite/Full split: decide on "Unsatisfied and ambiguous dependencies"
• Lite/Full split: decide on "The EventMetadata interface" #493 Lite/Full split: decide on "The EventMetadata interface"
• Lite/Full split: decide on "Defining new scope types" #494 Lite/Full split: decide on "Defining new scope types"

Personal opinion: I have added the TODO comments instead of just Asciidoc admonitions, because that allows easy tracking of the number of remaining open items (single grep command). I don't mind putting the content of the TODO comments into admonitions (and leaving an empty TODO comment alongside), but I believe this should all be primarily present directly in the Asciidoc source, so that context is immediately obvious. Tracking in GitHub issues is, in my opinion, secondary.

[manovotn]

All parts of this issue were done, closing now.