[Multimodal] Remove legacy multimodal fields in favor of MultiModalFeatureSpec

[sfeng33]

Purpose

This PR completes the migration to MultiModalFeatureSpec by removing legacy fields (mm_positions, mm_kwargs, mm_hashes) that were temporarily kept for backward compatibility. This is a follow-up to #23779 which introduced the unified MultiModalFeatureSpec data structure.
Fixes: #23872

Test Plan

python -m vllm.entrypoints.openai.api_server \
    --model llava-hf/llava-1.5-7b-hf 

curl -X POST "http://localhost:8000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llava-hf/llava-1.5-7b-hf",
    "messages": [
      {
        "role": "user",
        "content": [
          {"type": "text", "text": "What do you see in this image?"},
          {
            "type": "image_url",
            "image_url": {
              "url": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg"
            }
          }
        ]
      }
    ],
    "max_tokens": 100,
    "temperature": 0
  }'

[DarkLight1337]

Thanks for cleaning this up!

[DarkLight1337]

PTAL at the failing test

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @sfeng33.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[sfeng33]

Hey @zhewenl, this PR triggers the BC lint error due to the migration in NewRequestData's fields, could you advice on what to do here? I couldn't find the info from the wiki.

[zhewenl]

Hey @zhewenl, this PR triggers the BC lint error due to the migration in NewRequestData's fields, could you advice on what to do here? I couldn't find the info from the wiki.

You can follow the wiki here: https://github.com/pytorch/test-infra/wiki/BC-Linter#suppression

Either asking the committers to add the label to your PR or add the suppression in commit message should work

[sfeng33]

Hey @zhewenl, this PR triggers the BC lint error due to the migration in NewRequestData's fields, could you advice on what to do here? I couldn't find the info from the wiki.

You can follow the wiki here: https://github.com/pytorch/test-infra/wiki/BC-Linter#suppression

Either asking the committers to add the label to your PR or add the suppression in commit message should work

Thanks for your reply! I guess my question is - how to know if the change's linter can be safely suppressed? Since you just merged the linter change to NewRequestData, is it that there are some steps to take before making changes to the class?

[zhewenl]

Hey @zhewenl, this PR triggers the BC lint error due to the migration in NewRequestData's fields, could you advice on what to do here? I couldn't find the info from the wiki.

You can follow the wiki here: https://github.com/pytorch/test-infra/wiki/BC-Linter#suppression

Either asking the committers to add the label to your PR or add the suppression in commit message should work

Thanks for your reply! I guess my question is - how to know if the change's linter can be safely suppressed? Since you just merged the linter change to NewRequestData, is it that there are some steps to take before making changes to the class?

I see, in this case I think you can just suppress it - we are still piloting this feature and we are planning to roll out public interfaces - if the changes are approved by commiters, it's okay to suppress it.

[sfeng33]

Hey @zhewenl, this PR triggers the BC lint error due to the migration in NewRequestData's fields, could you advice on what to do here? I couldn't find the info from the wiki.

You can follow the wiki here: https://github.com/pytorch/test-infra/wiki/BC-Linter#suppression

Either asking the committers to add the label to your PR or add the suppression in commit message should work

Thanks for your reply! I guess my question is - how to know if the change's linter can be safely suppressed? Since you just merged the linter change to NewRequestData, is it that there are some steps to take before making changes to the class?

I see, in this case I think you can just suppress it - we are still piloting this feature and we are planning to roll out public interfaces - if the changes are approved by commiters, it's okay to suppress it.

Got you thanks!