Support prefetch/preload/dns-prefetch in the libraries API

I understand that for now, given the example, it is to add the possibility to specify additional "things" with the library that would generate the link tags. What about the existing external / js that are added in a library?
Should we do something like:

my_library:
  js:
   https://cdn.example.com/js/file.js: { type: external, preconnect: true, dns-prefech: true }

or

my_library:
  js:
   https://cdn.example.com/js/file.js: { type: external }
  links:
    -
      rel: preconnect
      href: //cdn.example.com
    -
      rel: dsn-prefetch
      href: //cdn.example.com
      

The second option allows a lot of flexibility (and cover the example of fonts) but is much more verbose.
Third option is a mix, allowing for shorter version for elements of the library (like example 1) and verbose version for other elements.

I am curious of a direction as we are for now implementing custom on a project but would be keen to write a patch for this to land in core the proper way.

I kind of like the more verbose option even for the same file, because you could have two files from the same CDN and then defining prefetch inline for one file (or both) doesn't seem ideal. We could always add a shorthand in a follow-up.

@catch thanks for the redirect to this issue. As I posted on the other issue, in my mind I think a definition like this would be nice;

font:
  css:
    base:
      https://fonts.example.com/font.css: { type: external }
  preconnect:
    https://fonts.example.com: {}
  preload:
    https://fonts.example.com/font-regular.woff2: { as: font, attributes: { type: font/woff2} }
    https://fonts.example.com/font-bold.woff2: { as: font, attributes: { type: font/woff2 } }

dns-prefetch would also have it's own entry. I think having separate entries instead of one generic 'links' entry reduces the risk of user error (and general misuse - eg putting css and js into the links entry). It's also clearer to read.