Где будет правильно расположить методы конвертации дто -> ентити и наоборот?
ты походу не догоняешь что такое дто и ентити. Умные западные чуваки энтити называют бизнесовую сущность со всякими бизнесовыми методами. Но из за аннотации в спринге такие как ты думают что это просто моделька для бд. Нет. А дто это просто модель данных без методов и этот объект нужен только для передачи данных в др место. 
методы конвертации
это называется маперы, и да, в джаве проще использовать либы для этого и это не только мапстракт. И ничего там не сложно 
под маперы можно сделать пакет рядом с репой, репа должна уже модели возвращать. Никто кроме репы про дто не должны знать
Добрый день!

Разместить прямо в дто в каждом.
Почему бы вам не добавить методы конвертации в сервисный слой, где вы пишете вашу бизнес логику.
Например, у вас есть entity User & dto - UserCreationDto. В сервисном слое UserService создайте 2 метода, которые конвертируют entity < -- > dto. 
Если вы используете встроенные возможности Spring (Converter<S, T>), то для каждого entity нужно создать свой класс. Что касается расположения пакетов, то есть разные практики. Например, в пакет user закинуть User, UserCreationDto, UserRepository, UserService, UserToDtoConverter и т.д.
Если вы никак не кастомизируете процесс конвертации, то можно написать один базовый класс с использованием generics.
Вот, простой пример для ModelMapper:
@Service
@RequiredArgsConstructor
public class MapperService {

  private final ModelMapper modelMapper;

  /**
   * Note: outClass object must have default constructor with no arguments
   *
   * @param <D> type of result object.
   * @param <T> type of source object to map from.
   * @param entity entity that needs to be mapped.
   * @param outClass class of result object.
   * @return new object of <code>outClass</code> type.
   */
  public <D, T> D map(final T entity, Class<D> outClass) {
    return modelMapper.map(entity, outClass);
  }

  /**
   * Note: outClass object must have default constructor with no arguments
   *
   * @param entityList list of entities that needs to be mapped
   * @param outCLass class of result list element
   * @param <D> type of objects in result list
   * @param <T> type of entity in <code>entityList</code>
   * @return list of mapped object with <code><D></code> type.
   */
  public <D, T> List<D> mapAll(final Collection<T> entityList, Class<D> outCLass) {
    return entityList.stream().map(entity -> map(entity, outCLass)).collect(Collectors.toList());
  }

  /**
   * Maps {@code source} to {@code destination}.
   *
   * @param source object to map from
   * @param destination object to map to
   */
  public <S, D> D map(final S source, D destination) {
    modelMapper.map(source, destination);
    return destination;
  }
}

Создать отдельный класс DTOUtils и все туда скинуть ( но тогда там вперемешку будут методы конвертации всех классов )
Не самая лучшая идея. Лучше так не делать. Вспоминаем про принцип единственной ответственности. (SOLID).

 Сделать пакет dtoutils и там создать много классов ( для каждого дто свой, они будут только хранить дто методы и все )
Все зависит от вашего проекта. Иногда наличие одного пакета может быть оправданно, а иногда нет. Важно корректно сформировать структуру проекта.

3 вариант выглядит как самый благоразумный, но создавать отдельный класс для одного метода это как-то не очень.
Это вот, как раз тот случай, когда вы используете интерфейс Converter<S, T>
https://docs.spring.io/spring-framework/docs/curre...
Если не хотите создавать по одному классу на каждый dto, то можете глянуть на код указанный выше. Может, это будет для вас полезно