`base64ct::Encoder` with alloc?

I'm migrating from base64 and notice that the following code snippet cannot easily migrate:

// before
    let mut buf = vec![];
    {
        let encoder = base64::write::EncoderWriter::new(&mut buf, &BASE64_STANDARD);
        let mut writer =
            arrow::ipc::writer::StreamWriter::try_new(encoder, &schema).or_raise(make_error)?;

        for batch in batches {
            writer.write(&batch).or_raise(make_error)?;
        }

        writer.finish().or_raise(make_error)?;
    }
    String::from_utf8(buf).or_raise(make_error)

// after
    let mut buf = vec![];
    {
        let encoder = base64ct::Encoder::<base64ct::Base64>::new(&mut buf).unwrap();
        let mut writer =
            arrow::ipc::writer::StreamWriter::try_new(encoder, &schema).or_raise(make_error)?;

        for batch in batches {
            writer.write(&batch).or_raise(make_error)?;
        }

        writer.finish().or_raise(make_error)?;
    }
    String::from_utf8(buf).or_raise(make_error)

Note that base64ct::Encoder accepts a &mut [u8] and thus you must know the result length beforehand.

In the contrast, base64::write:EncoderWriter takes W: io::Write so it takes &mut Vec<u8> whose write can grow the capacity on demand.

Although base64ct is defined to best effort being constant time, since it provides allloc feature for convience already, is it reasonable to implement a (new) Encoder that allocs on demand?

cc @tarcieri

Start by reviewing the existing base64ct::Encoder and its alloc feature, then compare the requested behavior with base64::write::EncoderWriter. Done would require an agreed design for an encoder that can grow its output on demand while preserving the project's constraints; the issue names no files or tests.