Remove the stale migration deprecations of ObjectClass and AttributeDescription

[vharseko]

Closes 54 of the 68 java/deprecated-call alerts left after #823 and #826 — the ones pointing at the SDK's own API — without touching a single call site.

The problem with these deprecations

ObjectClass.isPlaceHolder(), AttributeDescription.getNameOrOID() and the four AttributeDescription.create() overloads which take the user provided attribute name are all marked the same way:

     * @deprecated This method may be removed at any time
     * @since OPENDJ-2803 Migrate Attribute
     */
    @Deprecated

These are migration markers left by the SDK rework. They name no replacement, and there is none:

• a non-strict schema returns ObjectClass.newPlaceHolder(name) for an object class it does not know, and isPlaceHolder() is the only way of recognising it — short of asking the schema again by name with hasObjectClass(), which every one of the 27 call sites would have to do;
• getNameOrOID() returns the attribute name as the user provided it, preserving its case and any alias; getAttributeType().getNameOrOID() returns the primary name from the schema, and toString() appends the options, so neither is a replacement — swapping them in would change the attribute names the server echoes back in responses and LDIF;
• the create() overloads taking an attribute name keep that name in the resulting description, which the overloads without it drop.

The 54 calls are spread over the entry, schema, replication, plugin and control panel code. Keeping the markers therefore produces permanent code scanning alerts while telling nobody what to use instead.

What this change does

Drops the @Deprecated annotation and the @deprecated/@since tags from the six methods, and replaces them with a sentence explaining what each method is for and how it differs from the neighbouring, non-deprecated API — which is the information the marker was missing. No call site is modified, and no behaviour changes.

Alerts deliberately left open (14)

• DirectoryServer.getConfigEntry (9) — this deprecation is meaningful ("use getEntry(DN) when possible") and worth keeping for new code, but all nine call sites are backend and config-manager initialization, or the collection of user defined attributes from a configuration entry, where the virtual attribute processing of getEntry() must not happen. The advice does not apply to them.
• CoreConfigManager.isAllowAttributeNameExceptions (2) — its replacement, the ALLOW_MALFORMED_NAMES_AND_OPTIONS schema option, needs a schema from the server context. Both calls are in StaticUtils.isValidSchemaElement(), which is only called by the control panel schema editors while the user types a name, and a missing schema there would break the editor.
• ChangelogBackend.getInstance (2) — "instead inject the required object where needed": FileChangelogDB and ChangeNumberIndexer are created by the replication server independently of the backend, so this is a lifecycle change rather than a call replacement.
• Subject.getSubject (1) — Subject.current() requires Java 18; this project targets Java 11.

Testing

Annotation and javadoc only, no code path changes. opendj-core full test suite — 8173 tests, all passing; opendj-core packages including javadoc generation, and opendj-server-legacy compiles cleanly against it.