fix: Change the magic comment to be more clearly css-blocks related.

Author: chriseppstein

rfcs/rfc-ember-integration-v2.md

@@ -31,6 +31,7 @@ This project will be successful if it meets the following criteria:
 * Has a clear, testable contract between addon output and application inputs, including support and test matrices for older instances of CSS Blocks code.
 * Works well with addons that are using `yarn link` to develop in tandem with an application.
 * Unblock the planned "Block Passing" capability.
+* Both lazy and eager engines are working.
 
 # Summary of Architectural Changes
 
@@ -90,17 +91,17 @@ The goal of the compiled Block CSS file format is to
 A compiled block takes the following basic form:
 
 ```css
-/*#opticss-analyzed-styles-start:<block-id>*/
+/*#css-blocks <block-id>*/
 ... compiled output ...
-/*#opticss-analyzed-styles-end:<block-id>*/
 /*#blockDefinitionURL=pathToBlockDefinitionFile.block*/
+/*#css-blocks end*/
 ```
 
 There's three magic comments, let's walk through what they do:
 
-* `/*#opticss-analyzed-styles-start:<block-id>*/` &mdash; Indicates that the CSS that follows has been statically analyzed and is eligible for optimization by opticss. The block id must be 128 bytes or fewer.
-* `/*#opticss-analyzed-styles-end:<block-id>*/` &mdash; must be followed by the same id as a prior `opticss-analyzed-styles-start`
+* `/*#css-blocks <block-id>*/` &mdash; Indicates that the CSS that follows has been statically analyzed compiled by css-blocks. The block id must be 128 bytes or fewer.
 * `/*#blockDefinitionURL=pathToBlockDefinitionFile.block*/` &mdash; relative path to a block definition file or an inline url containing a base64 encoded file contents. The form of an inline URL for a block definition file is `/*#blockDefinitionURL=data:text/css;charset=utf-8;base64,<encoded-data>*/`.
+* `/*#css-blocks end*/` &mdash; marks the end of content compiled by css blocks.
 
 Additionally, the compiled output file may have a magic comment for an associated sourcemap.
 
@@ -113,7 +114,7 @@ The block definition file can be considered a serialization of the parsed Block'
 The block definition file differs from the source file in the following ways:
 
 * `@block`, `@export` &mdash; The path to the block file is now the relative path to the file that the block was compiled to.
-* `:scope` &mdash; A block-specific declaration of `block-id` with a quoted string value of the block's unique identifier (this id will match the block-id associated with the `opticss-analyzed-styles-(start|end)` comments)
+* `:scope` &mdash; A block-specific declaration of `block-id` with a quoted string value of the block's unique identifier (this id will match the block-id associated with the `css-blocks <block-id>` comment)
 * `resolve()` declarations &mdash; The value of the block's declaration is now stored in the css file. In the definition file we replace this block's declaration's value with `resolve-self()` to indicate the relative precedence of that block.
 * `@block-debug` at-rules are processed during compilation and removed.
 * `block-class` &mdash; This block declaration is only valid in a definition file. Each block style will have the CSS class name to which it was compiled set explicitly. These names might differ from the names that would be generated by the options the current process is using.
@@ -162,7 +163,7 @@ Consider the following source file:
 It would compile to:
 
 ```css
-/*#opticss-analyzed-styles-start:7d97e*/
+/*#css-blocks 7d97e*/
 .nav-7d97e {
   display: flex;
 }
@@ -178,8 +179,8 @@ It would compile to:
 .nav-7d97e__entry:hover {
   text-shadow: 2px 2px 1px;
 }
-/*#opticss-analyzed-styles-end:7d97e*/
 /*#blockDefinitionURL=nav.block*/
+/*#css-blocks end*/
 ```
 
 And to the following definition file:
@@ -265,7 +266,7 @@ the files from the addons.
 
 This addon will install a broccoli plugin that performs the following actions:
 
-1. Find CSS files that contain `/*#opticss-analyzed-styles-start:<block-id>*/` on the first line (because the block-id has a max length, we need only read the first 164 bytes of the file). If the magic comment is present and the block-id has not been encountered, read the whole file and it to the optimizer. If the block-id has been seen already, discard it. Don't transfer any files that were compiled from css-blocks to the output tree. (Note: We probably need to parse these compiled block files back into blocks, but we might be able to avoid it in the future.)
+1. Find CSS files that contain `/*#css-blocks <block-id>*/` on the first line (because the block-id has a max length, we need only read the first 144 bytes of the file). If the magic comment is present and the block-id has not been encountered, read the whole file and it to the optimizer. If the block-id has been seen already, discard it. Don't transfer any files that were compiled from css-blocks to the output tree. (Note: We probably need to parse these compiled block files back into blocks, but we might be able to avoid it in the future.)
 2. Find all the serialized template analysis files, deserialize them and add them to the optimizer. Don't transfer the template analysis files to the output tree.
 3. Run the optimizer and write the optimized stylesheet to a single CSS file in the application's styles directory (css-blocks.css). (Note: This file should be concatenated with the applications' other stylesheets. It should come after any resets and before any non-css-blocks styles.)
 4. Produce the data file that the css-blocks runtime helper will use to rewrite styles for each element. TODO: Figure out how to best get that file into the application bundle. We might need use the `app.postProcessTree('all')` hook to inject a "define" into the file into the application's JS bundle.