feat(DropdownMenu): add auto-locate prop

[inottn]

resolve #10661

[codecov-commenter]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (2f9f961) 89.89% compared to head (6321c72) 89.88%.
Report is 2 commits behind head on main.

Files	Patch %	Lines
packages/vant/src/dropdown-item/DropdownItem.tsx	88.88%	0 Missing and 1 partial ⚠️
packages/vant/src/utils/dom.ts	91.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12251      +/-   ##
==========================================
- Coverage   89.89%   89.88%   -0.02%     
==========================================
  Files         257      257              
  Lines        6801     6819      +18     
  Branches     1647     1653       +6     
==========================================
+ Hits         6114     6129      +15     
- Misses        366      367       +1     
- Partials      321      323       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[inottn]

修正偏移后就可以在 Popup、FloatingPanel 组件或用户自己的包含块组件中使用了。之后这个问题 #12121 也可以通过这种方式解决。

有一个问题，是否需要提供 prop 来由用户决定是否修正偏移呢？因为在正常场景下，不需要进行这一步操作。另外，根据实现逻辑，如果用户在展开下拉菜单后改变了包含块的样式，使得之前的包含块不再是包含块，也会导致定位出现偏差，尽管这种场景比较少见。

[chenjiahan]

方便补个测试用例嘛~

[chenjiahan]

是否需要提供 prop 来由用户决定是否修正偏移呢？

这个操作的性能开销是蛮大的，在毫秒级，可能会导致渲染的帧数下降，所以不太适合默认开启。

我们还是基于 prop 来开启吧~

如果用户在展开下拉菜单后改变了包含块的样式，使得之前的包含块不再是包含块

这种边界情况可以先忽略

[inottn]

是否需要提供 prop 来由用户决定是否修正偏移呢？

这个操作的性能开销是蛮大的，在毫秒级，可能会导致渲染的帧数下降，所以不太适合默认开启。

我们还是基于 prop 来开启吧~

如果用户在展开下拉菜单后改变了包含块的样式，使得之前的包含块不再是包含块

这种边界情况可以先忽略

这个 prop 叫什么好呢 🤔

[chenjiahan]

想了几个名字，你挑挑看

• locate-fixed-parent
• use-fixed-parent
• auto-locate

[inottn]

因为单测不太好写，拖了有点久。考虑后面类似需要调用 getComputedStyle 等 api 的场景，增加 e2e 测试。

[chenjiahan]

嗯嗯，目前单测是有一些局限性，e2e 可以作为补充