Support newer Jakarta Faces API versions: 3.0, 4.0, 4.1 (eclipse-jsf#8)

[bvfalcon]

Closes #8

Solution details:

1. New Facets (for Faceted Project) added: 3.0, 4.0, 4.1
2. New presets "Jakarta Faces 4.0", "Jakarta Faces 4.1", "JavaServer Faces 2.3" added
3. Added new menu item "New -> JSF File" with own wizard instead of creating JSF files with JSP files wizard

Known issues:

1. Documentation is not updated
2. Unit- and Integration-tests are not actualized, only adapted for code changes

[nitind]

Reexporting is an unusual choice these days. Why that change?

[nitind]

@bvfalcon Thank you for the substantial proposed changes. Some questions:

• jsf/plugins/org.eclipse.jst.jsf.core/plugin.properties has some unique strings removed, and the facet install actions deleted from the matching plugin.xml when it comes to older versions. The presets I can understand as they're for now-ancient versions, but the install action should still be relevant, right?
• I see what you're doing in (finally) establishing a dedicated content type for JSF files, but jsf/plugins/org.eclipse.jst.jsf.core/src/org/eclipse/jst/jsf/core/internal/preferences/JSFCorePreferenceInitializer.java:29 is currently set to alter the defaults in the JSP plug-in as the scope is determined through its symbolic name.
• The use of org.eclipse.jst.jsf.core.internal.project.facet.JSFUtils.isJavaEE(Object) to determine whether the standard's classes are in Jakarta packages or not will not support its use the way it is implemented. The WebApp version contents run up through version 6, so #isJavaEE() will return true regardless of whether the project is Java EE or Jakarta EE. A variation needs to be added that will take the WebApp version itself into account, with the callers acting appropriately (or something more specific like what you've added into JSFVersion). I would then like to go in an augment that to support conditions where the facet isn't installed, but the existence of the JSF libraries and the correct version can be determined through other means.
• Some of the local variable names in jsf/plugins/org.eclipse.jst.jsf.core/src/org/eclipse/jst/jsf/core/internal/provisional/contenttype/ContentTypeIdForJSF.java could use some jsp->jsf renames. It's not a blocker though, it looks correct otherwise.
• BREEs like in jsf/plugins/org.eclipse.jst.jsf.facelet.core/META-INF/MANIFEST.MF can only go upward, never downward. We can't drop below JavaSE-1.8 anyway because of ECJ dropping support for lower versions.
• jsf/plugins/org.eclipse.jst.jsf.facelet.core/src/org/eclipse/jst/jsf/facelet/core/internal/registry/taglib/faceletTaglib/util/FaceletTaglibValidator.java has an odd addition to the import statements.
• jsf/plugins/org.eclipse.jst.jsf.ui/src/org/eclipse/jst/jsf/ui/internal/wizard/NewJSFWizard.java is missing a copyright comment?