Come up with a clean approach for documenting 'experimental' features, and document it clearly

[fredemmott]

My definition of 'experimental' for this issue is any out of:

• explicitly experimental
• unannounced
• neither, but only usable with .hhconfig and HHVM settings

The last is the most relevant here.

This has came up with coeffects and capabilities, and now also with enum classes.

Documenting 'experimental' features that are nearly ready is desirable as:

• we want documentation to be ready when features are announced
• we do not want feature authors to have to write that documentation elsewhere

This is probably worth a dedicated document. It should cover:

• the .type-errors, .skipif stuff and markdown syntax for them
• whether or not the options should go in docs.hhvm.com's root .hhconfig
  • if so, I don't think they need a test-specific .hhconfig
  • if not, the .type-errors approach is needed
  • the HHVM configuration is needed either way
• how to test:
  • runtime and .type-errors: vendor/bin/hacktest tests/
  • no type erorrs: both that, and top-level hh_client
• what wording and formatting (bold, header, boxes etc) to use to document that it's not avialable by default yet