Refactor and abstract XNNPACK backend options #13190
Description
We should clean up backend option handling in the XNNPACK backend. Ideally, we want the following:
- Re-usable code to make adding new options easy.
- Make usage + handling robust (including error handling).
Ideally, this logic could be re-used by other backends, but it's not clear where to put it. I don't really want to introduce a new extension, as it doesn't feel like a good fit for an extension and it bloats the build. The core runtime would be a good place for it, but that would require fighting for binary size and dealing with embedded constraints. I'm inclined to just start with XNNPACK and go from there, but we'll see.