feat: swap 4462 proposal metadata and label localization

[nitrosx]

Description

This PR streamline showing the metadata for proposals and add localization to the proposals

Motivation

Showing metadata on proposals involves multiple configurations settings and a simplification was needed.
Following up the dataset labels localization, it was easy to extend to proposals

Changes:

• Proposal module
• Proposal details html page

Tests included

• Included for each change/fix?
• Passing? (Merge will not be approved unless this is checked)

Documentation

• swagger documentation updated [required]
• official documentation updated [nice-to-have]

official documentation info

If you have updated the official documentation, please provide PR # and URL of the pages where the updates are included

Backend version

• Does it require a specific version of the backend
• which version of the backend is required: BE PR still needs to be created

Summary by Sourcery

Add localization to proposal metadata and simplify metadata display configuration.

New Features:

• Added localization support for proposal metadata.

Tests:

• No tests were included in this pull request.

[sourcery-ai]

Hey @nitrosx - I've reviewed your changes - here's some feedback:

Overall Comments:

• The TODO comment regarding proposal type suggests a dependency on an unreleased SDK version. Consider either waiting for the SDK update or implementing proper handling for both current and future cases.
• The package.json version was changed from 4.5.0 to local.dev which appears unintentional. Please verify if this change was meant to be included in this PR.

Here's what I looked at during the review

• 🟡 General issues: 3 issues found
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion: Consider enforcing consistent key naming across components using string literal types

Different components are using inconsistent keys (e.g., 'proposal' vs 'dataset-default'). Consider using a string literal union type to enforce consistency, like: currentLabelSet: { [K in 'proposal' | 'dataset-default']: string }

Suggested implementation:

export type LabelSetKey = 'proposal' | 'dataset-default';

export interface LabelsLocalization {
  currentLabelSet: LabelSetKey;
  labelSets: {
    [K in LabelSetKey]: {
      [key: string]: Record<string, string>;
    };
  };
}

This change will require:

1. Updating any components that create or modify labelSets to ensure they only use the allowed keys
2. Potentially adding more literal types to the LabelSetKey union if there are other valid label set keys in use
3. Fixing any TypeScript errors in components that were previously using string keys not included in the LabelSetKey union