There is no such statement, because the DROP CONSTRAINT option requires you to name the constraint you want to drop. So, no, I wouldn't expect it to be on MSDN.
While you can create a constraint without explicitly naming it, it still gets a name. This is just a convenience that is allowed presumably because most of the time you create a constraint for good and don't later need to know or care what the name is. Generally, it is considered bad practice to let the system give your constraints a name, with the exception of certain types of constraints on #temp tables (due to concurrency collisions).
I suspect the syntax is only still allowed today to prevent backward compatibility issues, rather than because it's a good idea. In fact, if I were in charge of the MSDN docs, I would not describe the method below to drop an unnamed constraint, because all it would do is encourage this bad practice to continue.
Anyway, to drop a constraint when you don't know the name, you need to either look it up manually (armed with the names of the tables and columns involved), or use dynamic SQL. Here's an incomplete but working example of the latter:
DECLARE @fkname sysname;
SELECT @fkname = fk.name FROM sys.foreign_keys AS fk
INNER JOIN sys.objects AS parent
ON fk.referenced_object_id = parent.object_id
INNER JOIN sys.objects AS child
ON child.object_id = fk.parent_object_id /* parent of FK, not of child row */
WHERE parent.name = N'Parent table'
AND child.name = N'Child table';
-- best practice: also join twice to sys.schemas to ensure proper schema, too
DECLARE @sql nvarchar(max) = N'ALTER TABLE dbo.[Child Table]
DROP CONSTRAINT ' + QUOTENAME(@fkname) + N';';
PRINT @sql;
-- EXEC sys.sp_executesql @sql;
You can also have multiple foreign keys between the same two tables (and even FKs pointing to the same table), so you probably want other filters in there to make sure you drop the right FK. If you name your constraints instead of letting the system name them, this should become much easier.
