Cathal, thanks for the reply!
I was going to add the library reference to the code behind file. This lead me down another rabbit hole because the code behind file for the skin, ~/admin/Skins/skin.vb, didn't actually exist. Hmmm... That's interesting. I had seen the skin.vb file referenced in plenty of skins over the years, but I never thought to look at it before.
Well, after some googling a bit, I didn't find a definitive answer as to where the skin.vb file is located. It must be some sort of virtual file. However, I found a couple of posts that suggested that it was very rare for a DNN skin to have a physical code behind file. The popular opinion seems to be to use inline script tags, if necessary.
OK, so here's my current solution in case anyone else is experiencing a similar issue when using DDRMenu as a SolPartMenu replacement. I added the following lines near the top of the skin.ascx file:
<%@ Register TagPrefix="dnn" TagName="jQuery" src="~/Admin/Skins/jQuery.ascx" %>
<dnn:jQuery runat="server" jQueryUI="true" DnnjQueryPlugins="true" jQueryHoverIntent="true"></dnn:jQuery>
The jQuery, jQueryUI, and other DNN jQuery-related files are loaded using the DNN API to prevent conflicts in cases where they might be loaded more than once. I didn't find any documentation about using the DNN API to load the jQuery Migrate library, so it is loaded using the old fashioned method which might be subject to load conflicts. Hopefully it will be a rare module that tries to load jQuery Migrate library manually, though.
By the way, there's a great post by Jonathan Sheely that talks about properly loading jQuery in your skin:
Now the SolPartMenu template for the DDRMenu is happy and works in Chrome, IE, and Firefox without any issues:
<%@ Register TagPrefix="dnn" TagName="MENU" Src="~/DesktopModules/DDRMenu/SolPartMenu.ascx" %>