How do I extend the ThirdPersonCharacterControl standard assets to use new buttons?

What is the best practice for extending this functionality?

I don't think there's any accepted "best practice" to extend that particular component. I haven't used the standard assets much at all, but in general simply subclassing the existing type would be one way to add more features to an existing class. Of course the parent class may have private functions and what not to make the whole thing a bit harder or impossible, but it could be something to try first. That way you don't have to change existing code, but I have a feeling you ain't going to get away that easy.

Components are nice and separates concern nicely. Figure out what it is that the scripts already do and which part of their job you want to extend. For example, picking stuff up probably involves picking objects in the scene, displaying UI, animating character, stopping movement, playing sounds etc. Perhaps the last three is something that the 3rd person character would do, picking objects in the scene something that user control delegates to a raycaster. In that scenario it sounds like you want to modify user control/3rd party character and possibly add a raycaster component to the mix. It all depends on how tightly they need to interact with each other.

I would think that option #3 is the best option, but I won't be able to check for the presence of that component from within the Characters.ThirdPerson or CrossPlatformInput namespaces (these are handled in the .CSharp.Plugins solution, not my project's solution.

That's just because they sit in a special folder called "Standard Assets" which is compiled separately so UnityScript developers can use the scripts as well. If you rename that folder or move the files to a different folder, they'll be in the same assembly as the rest of your scripts.

I have a feeling my question just stems from not understanding how those solutions interact.

Well, have a look at Special Folders and Script Compilation Order. Basically Standard Assets types cannot depend on your types, but your types can depend on Standard Asset types. If you want, you could add an interface or a base class to Standard Assets, add modifications to Standard Assets to give it the ability to indirectly call your scripts. Your scripts can implement or inherit from those interfaces or base classes. That way they can talk between each other without Standard Assets directly depending on the types in your project.

If nothing else, I can just grab the source and put it in my own files, but I feel like it's better to reference the original script and build off it with my own components if possible.

Well, to be honest I think you'll find situations where you want to meddle with what goes on inside a method call. In those cases you'll want to modify the source. What is your concern about modifying the existing code? That in case someone drops an update of the source you'll have pain merging? Or something else? I wouldn't treat the standard assets as a holy grail, but a more interesting example than what they got on the website. The authors cannot predict how users want to extend on it and so there may be design flaws you want to correct to tailor for your specific project.