Block Build CLI output updates

[schlotterer]

1. Use “wds” as the namespace permanently - this will simplify set up and make the bocks more portable within WDS builds

   1. Convert any current namespaces to wds
   2. remove any notes in the find and replace about blocks namespaces
   3. leave the namespace customization option but don’t promote it as a default
   4. train engineers to work with client agnostic names in the blocks

2. Specific things to add to the cli functionality to be prebuilt:

   1. Auto generate block class via the block name and add it to the block
   2. get the block id and add it to the block
   3. setup some of the default gutenberg attributes https://www.advancedcustomfields.com/resources/blocks/
      1. anchor
      2. classname
      3. block align
   4. link back to the docks in each block
   5. Better escaping for attributes

[itsamoreh]

Use “wds” as the namespace permanently - this will simplify set up and make the bocks more portable within WDS builds

I love this! Does anyone know the reason we do the find and replace per-project?

[khleomix]

Even though the dynamic package naming approach might seem appealing, it's crucial to keep coding standards in mind. These standards recommend that functions within a theme should have namespaces aligned with the theme's name. Disregarding this guideline could potentially trigger a PHP CodeSniffer (phpcs) error stating that Namespaces declared by a theme/plugin should start with the theme/plugin prefix.

As an alternative, you could think about creating a child theme. This way, you could ensure consistent namespaces for both wd_f and wd_s. However, it's important to note that using wd_f and wd_s as parent themes doesn't align with their intended usage – they're designed as starter themes rather than parent themes.