BUG: Fix block styles not loading on frontend (fixed #1375)

[nerrad]

Problem this Pull Request solves

See #1375 for details.

The fix implemented here may or may not be the chosen route for long term fixes.

In #1286 I introduced the automatic dependency generation script and logic which in turn introduced the bug in #1375 because the frontend script for blocks (/src/blocks/index-frontend.js) doesn't list any dependencies on components, hence the @eventespresso/components built module is not loaded on the frontend. That module is where the styles for the component the event attendees block uses (components/event-attendees/style.css) are found. There are two temporary solutions:

1. Manually add @eventespresso/components as a dependency for the frontend css php side.
2. Manually import any styles we want included into /src/blocks/index-frontend.js (which would then get built to the /src/blocks/index-frontend.css file).

I chose the second option for the following reasons:

• Option 1 would result in a bigger package loaded over the wire on the frontend because ALL the styles for eventespresso components are loaded. Compounded with the yet unresolved problem of loading block assets on every route, this is not really desired.
• Option 2 allows for targeting only what is needed for frontend block loads. The downside of course is that in the backend, styles will be duplicated in both the "frontend" css and the main blocks css (loaded for the editor). I think for the backend that's okay.

Going forward as you plan for more blocks (not for this pull - but for future pulls), I would suggest evaluating:

• building block assets to their own files (I think this is what Jetpack does).
• look into only loading block assets on the routes they are needed. I would register block assets on every route, but then hook into the block parser code server side to determine whether to wp_enqueue the block assets by what blocks are detected. There is a pre_render_block filter in wp core that you might be able to use to detect when blocks are being rendered for post content and use that to enqueue the script/style (print style inline or enqueue script for footer). The other option is to use the parse_blocks function in core on an early hook (as soon as you know post_content) to detect if the post content has blocks (which is what you might want to use on a single post view).

How has this been tested

• Verify that the Event Attendee block assets load and display as expected on the frontend and the backend (editor).

Checklist

• I have read the documentation relating to systems affected by this pull request, see https://github.com/eventespresso/event-espresso-core/tree/master/docs
• User input is adequately validated and sanitized
• all publicly displayed strings are internationalized (usually using esc_html__(), see https://codex.wordpress.org/I18n_for_WordPress_Developers)
• My code is tested.
• My code follows the Event Espresso code style.
• My code has proper inline documentation.
• My code accounts for when the site is in Maintenance Mode (MM2 especially disallows usage of models)

[nerrad]

I expected this to happen for the package-lock in this case because of all the dependency updates merged into master without any rebuilds (dependabot updates)

[Pebblo]

Tested and confirmed the attendee block styles are applied in the admin and on the front end.