Respect schema-to-asset relationship when contributing assets

[nickgerace]

Description

This PR contains various changes related to respecting the one-to-one, schema-to-asset relationship that's presently in place. Normally, this PR description would be more detailed, but here is a rundown of the changes:

- Move module-related information in "app/web" to its own file in
  "api/sdf/dal/module.ts" (this is reflected in the frontend types
  crate)
- Move module syncing to the module store
- Convert ModuleExportModal to AssetContributeModal (the user domain
  language now understands _assets_ to be upgradeable, installable and
  contribute-able)
- Ensure AssetContributeModal only operates on what is passed down to
  it (avoids unnecessary computation since AssetListPanel is going to
  figure out what assets have "canContribute" set to "true" anyway)
- Reduce new contribution modal functionality to not have the ability to
  add or remove assets (I'm iffy on this one, but the "automatic")
  nature of preparing the request and the 1:1 nature of
  schemas-to-assets nudges me towards contracting and reducing failure
  modes in the interim... I'd add this with more time)
- Replace "module/export_module" with "v2/module/contribute" (we should
  consider a longer-term vision here domain wise... maybe this is all
  part of the asset concept and sdf should speak in assets?)
- Use 207 MULTI STATUS error for partial module contribution success
  when the dal is not at fault (e.g. 2 of 5 succeeded and the failures
  were only at the upload step)
- Use 502 BAD GATEWAY for total module contribution failure, but the dal
  was not at fault (e.g. 0 of 5 succeeded, but only at the upload step)
- Use 400 BAD REQUEST for malformed module contribution inpit
- Undo accidental buck2 support sync deps script commented out code
  on main
- Loosen "canContribute" constraints