ENH: implement pandas_timedelta_to_timedeltastruct for other resos
- [ ] closes #xxxx (Replace xxxx with the Github issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

cc @WillAyd IIRC you implemented the original here.  The new cases this implements are mostly copy/paste, so it wouldn't surprise me if there is a more elegant alternative.  Thoughts?
> If so you might want to opt for a macro'ed approach similar to what's in khash.h rather than copy / pasting these.

my thought was to follow the pattern for the dt64 code in the same file, which would probably mean refactoring out some helper functions but not using macros.  Is getting comfortable with macros the next step of leveling up my C-fu?
 The macros would definitely be more advanced, at least as far as I understand. I am by no means an expert and not in a good enough position to teach, but from my personal experience the biggest things I've found to help grasp C are:

  - Treating every warning as an error. -Wall, -Wextra and -Werror are great switches; while C has some historic cruft in what the language will allow, most compilers do a great job of warning you about things that may be technically valid but not what you want
  - Getting comfortable with the debugger. gdb and lldb are great tools, and aren't a huge leap from pdb. The only thing to be aware of here is that if you want to debug a library you will also want to compile that library with debugging enabled, otherwise a lot of the function names, symbols and bodies will be stripped down to assembly

https://pandas.pydata.org/pandas-docs/stable/development/debugging_extensions.html might also help Thanks.  Any objection to merging as-is?  We may implement more units later, but this gets all the ones we're definitely doing. i guess it would make sense to have a corresponding function to go from tdstruct to td64. was that just not necessary at the time when it was nanos-only? None from me. My feedback is just long term consideration but I think it’s great to move forward with what’s there and consolidate later > Not user facing necessarily right?

nope, just needed to implement non-nano Timedelta