#0 what is the format? As you partly guessed, that is the "PEM" armoring of the DER encoding of the SubjectPublicKeyInfo ASN.1 type from X.509, republished for Internet use as RFC5280 section 4.1 particularly 4.1.2.7. To support multiple algorithms including new ones in the future, this structure is a SEQUENCE of an AlgorithmIdentifier which identifies the algorithm (using an OBJECT IDENTIFIER for the algorithm and various types for parameters depending on the algorithm), followed by a BIT STRING that contains the key value encoded in a format that varies depending on the algorithm. The AlgId and key format specific to ECDSA (and ECDH) are in RFC3279 section 2.3.5 although you can ignore the complicated parts about ECParameters because in practice everyone uses the simpler namedCurve OBJECT IDENTIFIER option, and the key format is just the SEC1/X9.62 point.

Here 301006072a8648ce3d020106052b8104000a is the AlgId and decodes as

    0:d=0  hl=2 l=  16 cons: SEQUENCE
    2:d=1  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   11:d=1  hl=2 l=   5 prim: OBJECT            :secp256k1

(As you've already figured out, "PEM" is just base64 of the DER, with line breaks at intervals, plus a ----BEGIN whatever----- line at the top and an -----END whatever----- line at the bottom.)

#1 encode without python? Aside from implementing (part of) DER yourself, which isn't that hard if you want, I see the page you link to talks a lot about OpenSSL compatibility: for programs in C or languages that can (easily) call C, which is many, OpenSSL can generate, read, write, and use for various operations ECC keys in this format (and the un-armored DER form). Java 7+ cryptography can do it, but the standard providers only in DER; for PEM you have to en/de-armor yourself or use http://www.BouncyCastle.org instead. I expect dot-NET can do it, but I don't use that and can't say definitely. I know I've seen perl modules for DER, but somehow I can never find things in CPAN even though that's its purpose. If you want a more specific answer, revise your question (or if it's sufficiently different, ask a new one).

#2 private key? That page says it uses -----BEGIN EC PRIVATE KEY----- which could be either of two 'legacy' formats in OpenSSL: unencrypted or encrypted. Since the examples don't show any password, I'll assume the former. If you look at a key file and see lines about Proc-type and DEK-info inserted after the -----BEGIN line but before the base64 data, it's legacy-encrypted and that's more complicated.

Without that, it's the private key structure defined by the SEC1 document at http://www.secg.org/ in C.4, which contains an OCTET STRING for the private key (actually an integer, but not encoded as such), parameters defined in C.2 which if you examine carefully are essentially equivalent to those in RFC 3279, and once again a BIT STRING containing the public key (a point).

OpenSSL also supports the "new" (as of about 2000!) PKCS#8 format for private keys. Much like X.509 SPKI for public key, this is a generic wrapper that is basically an AlgorithmIdentifier for the algorithm plus an OCTET STRING containing the key value depending on the algorithm, except that PKCS#8 also has an option for encrypting at the PKCS#8 level (as opposed to the "PEM" level). I don't know if the python module handles these formats or not, and if not, whether you would want to use them and thereby be incompatible with the python module. If you don't want to use PKCS#8 and do want to use OpenSSL, be careful to use the specific EC routines not the generic ones.