As @mvevitsis says, it’s not that simple because that still wouldn’t bring the device into your SmartThings account.
If you really can’t imagine giving up Webcore or some other groovy smartapp, the simplest solution is likely to switch those use cases to a Hubitat hub, which will run Groovy locally.
It would be a big project, you’d need to also add a raspberry pi so SmartThings and Hubitat could talk to each other, I think you’d have to rebuild all your pistons on the new platform, but you would still have Webcore.
Might be worth it for someone who has several Samsung smart tvs and appliances or just doesn’t want to lose the ST app, is comfortable learning mqtt if they don’t know it already, and is heavily invested in being able to write new Webcore pistons or has other existing groovy projects they don’t want to give up. But way too much work and complexity for most people, I think. 
Hubitat to run Webcore, MQTT to integrate back to SmartThings
Here’s how this would work.
-
use Hubitat to run Webcore. I believe you would have to recreate all your pistons over there, but I don’t know the details.
-
Use proxy virtual devices on one system or the other. If you create virtual devices on Hubitat, you could leave the actual zwave and Zigbee devices on your SmartThings hub. Or you might have some devices that need custom code not yet available in an Edge driver, so you move those devices over to hubitat to take advantage of groovy there and add a proxy virtual device for them on the ST side.
There would be a lot of code needed to synch everything up, but you wouldn’t have to reset any physical devices that worked with an Edge Driver.
- Hubitat has a built-in interface to communicate with an MQTT broker. And @taustin has written a SmartApp for the new platform that supports communications with an MQTT broker. So you could communicate between the two hubs that way.
The good news is everything would run locally. The bad news is this is obviously just for power users willing to run 3 systems. But it should be doable.