Any non-spec-defined marking definition type should be accepted by the library

[chisholm]

"Custom" content has a specific meaning, described in (deprecated) section 11 of the spec. These include custom properties, objects, and extensions. It does not include markings. There is effectively no such thing as a "custom marking", as far as the spec is concerned. Section 7.2.1.1 only says the definition type should be tlp or statement, so we must allow any other definition type as well, regardless of the allow_custom setting.

It is also undesirable to force users to pre-register things for a parse to work without errors. If the amount of content is large and they didn't create it, it can be hard to know what's in the content and what to register. Content should be accepted with simple fallback behavior when there is no registration (e.g. just pass through the dict). So this should be the case for markings too. There should be no error if a definition type doesn't have a marking class registered for it.