Fix ensure blocks array not null before component update

[satrun77]

Description

Ensure blocks properties in ElementList::componentDidUpdate are not null before calling map method. This is to prevent breaking the elemental area field while it is rendering, and the content author clicks the save or publish buttons too quickly.

Manual testing steps

1. Install fresh CMS
2. Add Elemental module
3. Create a data object with version and more than one elemental area

use DNADesign\Elemental\Extensions\ElementalPageExtension;
use DNADesign\Elemental\Models\ElementalArea;
use SilverStripe\ORM\DataObject;
use SilverStripe\Versioned\Versioned;

class SomeObject extends DataObject
{
    private static string $table_name = 'SomeObject';

    private static array $db = [
        'Title' => 'Text',
    ];

    private static array $has_one = [
        'BlockArea' => ElementalArea::class,
        'BlockArea2' => ElementalArea::class,
    ];

    private static array $extensions = [
        Versioned::class,
        ElementalPageExtension::class,
    ];
}

6. Create a model admin for the data object.

use SilverStripe\Admin\ModelAdmin;

class SomeAdmin extends ModelAdmin
{
    private static string $url_segment = 'objects';

    private static string $menu_title = 'Objects';

    private static array $managed_models = [
        SomeObject::class,
    ];
}

8. Open browser console > Network tab
9. You will see multiple requests for /admin/graphql for each elemental area

10. Click publish just before all of the requests are completed, and you will see the pending ones changed to cancelled. The requests may load fast, which makes it hard to replicate. I edited the controller SilverStripe\GraphQL\Controller, and added sleep(1); to index method to slow down the request.

11. Saving or publishing the data object must be completed without any issue
12. The error about accessing map on null, must not be throwing in the console

Issues

• #Elemental area stop rendering after save/publish clicked #1293
• #Publish/Save button not responding silverstripe-admin#1871

Pull request checklist

• The target branch is correct
  • See picking the right version
• All commits are relevant to the purpose of the PR (e.g. no debug statements, unrelated refactoring, or arbitrary linting)
  • Small amounts of additional linting are usually okay, but if it makes it hard to concentrate on the relevant changes, ask for the unrelated changes to be reverted, and submitted as a separate PR.
• The commit messages follow our commit message guidelines
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

[GuySartorelli]

LGTM, works locally. I can't think of a way this would cause new problems so should be fine in a patch. Thanks for submitting this!