BUG: Bugs with stc.save behavior

Currently if you do stc.save("test.h5") and it's a surface source estimate, it will save test.h5-lh.stc and test.h5-rh.stc files because the default is ftype="stc", and these must be saved in two separate files. If you instead stc.save("test-lh.stc"), it will end up writing test-lh.stc-lh.stc and test-lh.stc-rh.stc files. This is documented behavior but I think we could improve it by:

1. Changing the ftype="stc" default to be ftype="auto", which would mean: infer from the extension if possible, otherwise assume "stc"
2. Change the behavior for ftype="stc" to only add the -lh.stc to the filename if it's not already there.

This would have led to the much more intuitive behaviors that doing stc.save("test.h5") would have saved a single test.h5 file, and doing stc.save("test-lh.stc") would have saved to the two files test-lh.stc and test-rh.stc. It makes for much nicer saving and checking at the user end because you can have a single path like test-lh.stc, check for its existence, and if missing then save -- all without needing to compensate for magic stuff in the paths you pass around.

This will create a small backward compat break for people who were relying on the double-naming -lh.stc-lh.stc at the end of a filename, but I think hopefully those cases are rare enough to be worth the tradeoff of what I think is much clearer, intuitive behavior.

Start by locating the stc.save entry point and the existing handling of the ftype argument and surface-source filenames. Check how extensions are inferred and how left/right STC paths are generated; done means the proposed test.h5 and test-lh.stc cases produce the stated paths without the double suffix, with existing save behavior covered.