Add some missing package dependencies

[anomiex]

!-- Thanks for contributing to Gutenberg! Please follow the Gutenberg Contributing Guidelines:
https://github.com/WordPress/gutenberg/blob/trunk/CONTRIBUTING.md -->

What?

Add some missing package dependencies

Why?

Build code transformations can introduce dependencies on packages such
as @wordpress/element and @babel/runtime. These need to be declared if
the package is to function correctly with yarn's p'n'p or pnpm with
hoisting disabled.

• @wordpress/preferences depends on @wordpress/element (fixes @wordpress/preferences is missing a dependency on @wordpress/element #41341)
• @wordpress/reusable-blocks depends on @babel/runtime (fixes @wordpress/reusable-blocks is missing a dependency on @babel/runtime #41343)
• @wordpress/viewport depends on @wordpress/element (fixes @wordpress/viewport is missing a dependency on @wordpress/element #41346)

How?

Adding the missing dependencies. Normally I'd probably have done the @babel/runtime dep as a peer dep, but I see you use a normal dependency everywhere else so I followed along.

Testing Instructions

1. Follow the reproduction instructions in the linked bug to set up the test and reproduce the bug.
2. Do yarn add <package>@file:/path/to/gutenberg/packages/<package> or (with pnpm 7) pnpm add <package>@file:/path/to/gutenberg/packages/<package> to point yarn or pnpm at the locally built version of the package.
3. Repeat the final instruction in the reproduction to check that the bug is fixed.

[anomiex]

Unit test failure in https://github.com/WordPress/gutenberg/actions/runs/5326375963/jobs/9648351381?pr=41486 seems unrelated.

[gziolo]

Thank you for adding the missing dependencies. Can you think of a programmatic way to prevent this type of issues to happen again?

Normally I'd probably have done the @babel/runtime dep as a peer dep, but I see you use a normal dependency everywhere else so I followed along.

Yes, that should be changed to a peer dependency when we move Node 16+ and the latest npm.

[anomiex]

Thank you for adding the missing dependencies. Can you think of a programmatic way to prevent this type of issues to happen again?

Not offhand. You'd probably have to find/make some sort of tooling to extract all the deps from the built files and see that they're either depended on or peer-depended on by the package.

[gziolo]

Thank you for adding the missing dependencies. Can you think of a programmatic way to prevent this type of issues to happen again?

Not offhand. You'd probably have to find/make some sort of tooling to extract all the deps from the built files and see that they're either depended on or peer-depended on by the package.

Ok, it makes sense. We have some linting rules in place from eslint-plugin-import that work nicely with the source code, but they don't cover the parts dynamically modified by the Babel plugin that gets published to npm inside build-module folders. We potentially could extract these rules and run them against build-module folder in a separate process on CI.