Force all serializer encoders + normalizers services to be private

This has tests that are very explicit and they clearly indicate that the functionality is working. This looks like a good way to make this internal functionality not exposed to the outside.

Can we have Grayside's feedback over here as well on whether this resolves his concern?

Because this does look like a BC break. As such, it'd also need a change record.

I'm not sure if I understand the implications of private services well enough to say whether it's a use case problem.

I've read http://symfony.com/blog/new-in-symfony-3-2-improved-private-services and http://symfony.com/doc/current/service_container.html#public-versus-priv..., and if I understand correctly, our goal in making these services private is primarily to avoid them being accessed by static code, but not to prevent their use and abuse when injected as a service. I guess the intention is to inhibit the misuse of normalizers in procedural code?

The case I raised in the previous issue would have developers that need to do awkward things in custom formats with a pattern such as the following pseudo-code:

my_hal/my_hal.services.yml

services:
  serializer.normalizer.entity_reference_item.my_hal:
    class: Drupal\my_hal\Normalizer\EntityReferenceItemNormalizer
    arguments: ['@rest.link_manager', '@serializer.entity_resolver', '@serializer.normalizer.field_item.my_hal']
    tags:
      - { name: normalizer, priority: 10 }

my_hal/src/Normalizer/EntityReferenceItemNormalizer

class EntityReferenceItemNormalizer extends HalEntityReferenceItemNormalizer {

  public function __construct($arg1, $arg2, FieldItemNormalizer $normalizer) {
    $this->fieldItemNormalizer = $normalizer;
   }

  /**
   * {@inheritdoc}
   */
  public function normalize($field_item, $format = NULL, array $context = []) {
    $target_entity = $field_item->get('entity')->getValue();
    if ($this->shouldEmbedAsGenericField($target_entity)) {
      return $this->fieldItemNormalizer->normalize($field_item, $format, $context);
    }
    return parent::normalize($field_item, $format, $context);
  }
}

If that is correct, then marking these private is fine from a pure capabilities standpoint for developers to effectively vary serialization formats. However, anyone that's previously used \Drupal::service('serializer.normalizer.field_item.my_hal') as an ugly hack will of course be burned by an incompatibility. I don't see a way around that here without either adding a B/C layer or deciding that this is an exception case because clearly using the static wrapper to abuse the normalization process was not intended.

Also, as I noted in the other issue, I have seen a developer use a complex contrib encoder/decoder to do some data parsing where all they cared about was correctly deriving an intermediate, unclassed data structure. It's less clear in my mind that encoders/decoders should be locked to the serialization system. Is this primarily to ensure higher priority encoders for a given format will be loaded properly for all calling code? That said, if you do need to use an encoder outside serialization, it doesn't seem that big a problem to insist they register the class as a custom service.

@Grayside - are you happy with the responses from @Wim at #10

Yes, that response clarifies the goals of this change and confirms my code in #9 is the intended direction for edge case private normalizer use.

Can we get a change record here, I suspect this might cause some issues for people who're using them incorrectly.

Committed/pushed to 8.6.x, thanks!

This missed the alpha, so leaving it out of 8.5.x for now, will update the change notice when I publish it.