fix: improve block labels and aria roles

[maribethb]

The basics

• I validated my changes

The details

Resolves

Fixes #9802
Fixes #9804
Partially addresses #9793 (actually does fix it technically but making a follow up change related)
Fixes #9790
Fixes RaspberryPiFoundation/blockly-keyboard-experimentation#789

Proposed Changes

• only include "replaceable" text for shadow blocks in verbose output, as requested by microbit
• only include field type info in verbose block text, or when a field itself is focused
• don't include custom input labels in block text. the custom labels will be used in a couple other places instead, in follow up PRs (one for move mode mike is working on and one for an issue we've discussed over chat and haven't filed yet)
• don't include "begin stack" in the flyout or in move mode
• fix up full-block fields markup
  • this is complex because the way we determine whether or not a block is a full-block field block is dumb. i'm making a follow up change to address that, but it's a breaking change, and i wanted to separate it out.
  • also complex because we handle this by returning the field's focusable element as the block's focusable element, which is weird. there's a bit of tomfoolery needed to make this work with the id of the field, but otherwise it's not too bad.
  • a bunch of logic to make sure we're setting the role and label correctly for these fields that are pretending they're blocks.
  • added a getFullBlockField method to facilitate checking this. this is different than what's in the design doc for reasons i put in a comment in the design doc.
  • improved the jsdoc for the isSimpleReporter method to better explain what that means.
  • since the logic for whether/how to set aria markup for full-block fields is complex, i moved it to the base field class and had subclasses override it where needed to set customized labels and other states.

Reason for Changes

Makes aria markup better

Test Coverage

Fixed the tests, removed some that assert behavior we don't actually want.
I skipped some tests related to custom input labels because I'm about to implement the custom input labels in a separate PR and I'll unskip them then.

Documentation

maybe for setting aria for custom fields, but it depends how we write the documentation.

Additional Information

[maribethb]

Updated to account for the merge conflict with showing custom input labels in move mode. Required adding a new parameter to control if the custom labels should be used or not.

Also updated the move announcement tests to be a little bit less flaky. I did remove one assert because I think it's correct that the announcement is "moving inside custom else if input of if do else if do" but let me know if you think that's not correct

[mikeharv]

Thanks for shoring up the tests. My suggestion isn't blocking, but I noticed we might be calling getAriaLabelText() when we don't always need to.

[mikeharv]

Nit: This could also be

const customLabel = useCustomLabels
  ? input.getAriaLabelText()
  : null;

return customLabel ?? input.getLabel(verbosity);

This could be worthwhile just because we don't know how heavy a label provider function might be and it saves us having to execute it if not needed.