I think for now, 1 - Do Nothing because the provisioning stuff is soon enough going to allow something like 3. How?
A package related to elytron will have an optional dependency on a package related to jaspic. Since it's optional it won't be included in a default provisioned server.
A jaspic "feature" (part of the elytron configuration) will have a hard dependency on that jaspic package. So if the provisioning spec includes that feature, the package will be included in the install.
Something in full could possibly also have a hard dependency on jaspic. (Maybe not I don't know the EE details.) If so having that thing present would also ensure the jaspic package is included.
The semi-edge case is the user provisions something with no hard dep on the jaspic package, and then wants to come along with the CLI/HAL and configure jaspic. Won't work. The management handlers should deal with that with some nice error message.
Another variant is the jaspic package is an optional dep but is included by default, avoiding the semi-edge case. So the dist is bigger than needed, but the provisioning tool makes it easier to exclude it than it is now, since the provisioning file can declare that the jaspic package isn't wanted via a simple exclude element.
Bottom line is I think the provisioning tooling is going to ease the pain of slimming enough that jumping through hoops to make our feature packs smaller becomes less necessary.