Sandbox Solutions are still supported in SharePoint.  But the subtle distinction is that Sandbox Code Service is switched off.  So solutions with Sandbox Code will not activate.

Activation of solutions with sandboxed code has been disabled in this site collection.

But I argue that No-Code Sandbox Solutions is still the best way to build and package assets like JavaScript, images, CSS to be deployed to SharePoint - works in SP2010, SP2013, and SPO.

So the one trick is you have to build it excluding the DLL that it compiles.

TLDR:

OK the deeper details:

By default, the sandbox solution project include assembly in package.  So when you build the solution, it includes the DLL.

When you set the project to "not include assembly in project", then the result is now "SPO-sandbox friendly"

What if I don't have the project, I just have a WSP?

You really need to know the ins and outs of the sandbox solution - what's in it, and what does it do.  But the line of thought goes

1. Open up the WSP file with a CAB utility.  Consider IZArc - you will need to extract the contents, make your changes, then package the folder structure back into a new CAB file.
2. Delete the assembly reference in the solution manifest.xml
3. Repackage the WSP file and pray. 
   There are a lot of reasons why this might not work - if your package has feature or event receivers or sandbox WebParts that actually uses the code which is now missing - things will fall over (hopefully, quickly). 
4. Please test in a separate test environment, at least a different site collection on the tenant.

When re-packaging

• delete the assembly xml section
• don't include the DLL again in the new CAB file.

Good luck!